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programming  languages  and  data  management  systems.  It  also  provides 
a tutorial  and  reports  on  simulation  tasks  which  are  specific  to 
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Overview  of  the  Contract  Period 

The  objectives  of  the  contract  period  were  to  explore 
developments  in  the  use  of  large  scale  general  purpose  computers 
for  Air  Force  data  processing  needs  in  four  broad  areas:  parallel 
processing,  programming  languages,  modeling  and  performance 
evaluation  of  generalized  data  management  systems,  and  systems 
studies . 

These  developments  were  accomplished  by  principal  investiga- 
tors in  each  area  working  with  other  research  personnel,  faculty 
and  students  in  each  of  the  four  broad  areas. 

In  this  section,  each  principal  investigator  summarises  the 
accomplishments  in  each  of  their  areas  of  investigation. 

References  are  made  to  interim  reports  published  by  RADC  and  other 
works  produced  during  the  period.  Those  unique  references  (i.e. 
not  fully  described  in  published  reports) , are  part  of  this  report. 
The  references  in  each  of  the  four  areas  summarized  by  the  principal 
investigators  give  the  section  number  of  the  referenced  report  in 
this  report  or  references  to  other  documents. 
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1.  PARALLEL  PROCESSORS 


E.  P.  Stabler,  Principal  Investigator 

1.1  This  summary  is  divided  into  a series  of  descriptions  of 

work  done  on  various  aspects  of  the  Large  Scale  Information  Systems 

Project. 

Air  Traffic  Control  is  an  important  application  area  for 
parallel  processing.  A study  was  made  of  the  processing  require- 
ments and  parallel  algorithms  for  air  traffic  control. 

A diverse  collection  of  low  cost  LSI  microprocessors  and 
microcomputers  has  become  available.  Modern  engineering  designs 
make  extensive  use  of  these  items.  A collection  was  made  of 
descriptive  engineering  material  on  commercially  available 
processors  and  systems  to  aid  in  evaluation  of  alternatives. 

Sorting  networks  and  various  kinds  of  parallel  data  movement 
networks  are  important  in  parallel  processing  systems.  Data 
movement  and  data  positioning  can  cause  bottle-necks  which  reduce 
the  effectiveness  of  parallel  processing.  Several  studies  were 
made  of  data  movement  networks. 

A system  of  mixed  mode  carryless  arithmetic  was  developed  and 
implemented  on  STARAN.  The  mixed  mode  system  allows  STARAN  to  do 
parallel  arithmetic  without  incurring  the  delays  associated  with 
carry  propagation.  The  study  was  continued  to  include  development 
of  4 bit  digit  encoding  and  arithmetic  processes  waich  would  be 
suitable  for  a STARAN-like  configuration  processing  4 bit  data 
objects.  The  arithmetic  unit  for  processing  in  this  form  was 
designed  using  high  speed  LSI  processor  chips. 
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A method  of  simulating  high  speed  random  logic  networks  on 
STARAN  was  developed  and  programmed.  Random  arrangements  are 
the  most  difficult  to  simulate  using  the  highly  regular  STARAN 
structure.  In  this  case  regularity  was  achieved  by  coding  the 
gate  functions  and  the  interconnection  as  data.  Very  high  speed 
logic  simulation  capability  was  obtained. 

G.  Foster  joined  the  effort  in  June  1976  and  worked  on  the 
following  four  tasks: 

1.1.1  A study  of  an  earlier  effort  to  define  a machine 
architecture  for  the  direct  execution  of  a subset  of  Space 
Programming  Language  Mark  IV  (SPL)  was  studied  and  an  informal 
critique  was  prepared.  The  architecture  description  of  the  Space 
Programming  Language  Machine  (SPLM)  and  its  logic  simulator  (CLS) 
were  described  in  APL.  It  was  felt  that  non-trivial  changes  were 
made  in  SPL  in  implementing  the  SPLM. 

1.1.2  A partial  bibliography  and  selected  readings  in  the 
literature  pertaining  to  the  direct  execution  high  level  languages 
has  been  prepared  and  informally  submitted  for  evaluation. 

1.1.3  Some  assistance  in  following  the  developments  of 
language  constructs  for  multi-and  parallel  processing  has  been 
given  to  RADC  personnel.  In  addition  H.  A.  E.  Spaanenburg,  who 
has  been  associated  with  the  contract  until  his  termination  this 
past  summer,  is  independently  pursuing  research  in  this  general 
area. 
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1.1.4  Readings  in  the  areas  of  horizontal/vertical  micro- 
programming trade  offs  have  been  undertaken  preliminary  to  greater 
study  of  the  QM-1.  Further,  some  early  findings  in  the  areas  of 
functional  support  for  computing  ensembles  are  now  being  sharpened. 

The  work  on  the  STARAN  system  included  the  writing  of  an  APL 
interpreter  system  which  used  the  STARAN  processor  for  all  the 
arithmetic  processing  and  data  storage  and  using  the  PDP-11  for 
program  storage  and  interpretation.  The  two  processes,  interpre- 
tation and  arithmetic,  were  performed  simultaneously  in  the  two 
processors  resulting  in  high  utilization  of  the  equipment  and 
high  speed.  This  work  was  done  by  J.  Marzolf  and  was  reported 
in  reference  1.2.8. 


1.2  Publications  - PARALLEL  PROCESSORS 

1.2.1  Chen,  I.  N. , "A  Cellular  Data  Manipulating  Array," 
Proceedings  of  1975  Sagamore  Conference  on  Parallel  Process- 
ing , pp.  114-115. 

1.2.2.  Feng,  T.  Y. , Chen,  I.  N. , and  Chen,  Y.  K. , 

"Associative  Processing  of  Network  Flow  Problems,"  RADC 
Report  TR-76-93,  March  1976,  ad  # A024  392. 

1.2.3.  Feng,  T.  Y.  and  Cheng,  W.  T. , "Analysis  and  Design 
of  a Cost  Effective  Parallel  Processor  for  Weather  Computa- 
tions," Parallel  Processing,  Springer-Verlag,  pp.  53-75. 
(Section  6 of  this  report.) 

1.2.4.  Feng,  T.  Y.  and  Hsu,  C.  P.,  "A  Reconf igurable 
Parallel  Arithmetic  Unit,"  Parallel  Processing,  Srpinger- 
Verlag,  1975. 

1.2.5.  Feng,  T.  Y.  and  Lee,  C.  C. , "Sorting  algorithms  for 
Parallel  Processing,"  Proceedings  of  1975  Sagamore  Conference 
on  Parallel  Processing,  pp.  239-240. 

1.2.6.  Feng,  T.  Y.  and  Lee,  C.  C.,  "Parallel  Multitonic 
Sorting  Networks,"  RADC  Report  TR-76-93,  March  1976  , AD  # 024392. 


1.2.7.  Feng,  T.  Y.  and  Yang,  S.  M. , "An  Approach  of 
Developing  Fast  Transform  Algorithms,"  RADC  Report  TR-76-92, 
March  1976  , AD  # 9024  665. 

1.2.8.  Marzolf,  J.  G. , "AAPL,  An  Array  Processing  Language, 
Parallel  Processing,  Springer-Verlag , 1975. 

(Section  7 of  this  report.) 

1.2.9.  Stabler,  E.  P.,  "Mixed  Mode  Arithmetic  for  STARAN," 
Parallel  Processing,  Springer-Verlag,  1975,  pp.  228-230. 
(Section  14  of  this  report.) 

1.2.10.  Stabler,  E.  P.  and  Hsu,  I.,  "Parallel  Arithmetic 
Using  Serial  Arithmetic  Processors,"  RADC  Report,  Sept.  1975 
(Section  15  of  this  report.) 

1.2.11.  Marzolf,  J.  G. , "The  Design  and  Implementation  of 
APL- STARAN. " 

(Section  13  of  this  report.) 
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2 . PROGRAMMING  LANGUAGES 

J.  C.  Reynolds,  Principal  Investigator 

2.1  An  extension  of  the  typed  lambda  calculus  has  been  developed 
which  permits  the  binding  and  application  of  types.  While  retain- 
ing complete  compile-time  type  checking,  this  language  provides 
polymorphic  functions  and  user-defined  types.  A semantic  model 
has  been  formulated  using  Scott's  lattice-theoretic  approach.  At 
present,  we  are  trying  to  extend  this  language  and  its  model 
to  include  the  recursive  definition  of  types.  Reference  2.6.1. 


2.2  User-defined  types  and  procedural  data  structures  have  been 
shown  to  be  complementary  tools  for  data  abstraction.  Each 
approach  has  its  own  distinct  advantages  and  limitations,  and  the 
two  approaches  cannot  be  unified,  except  by  combining  their 
limitations.  Reference  2.6.2. 

2.3  D.  Scott  has  shown  that  a simple  imperative  language,  in 
which  primitive  instructions  are  combined  using  sequencing  and 
conditional  operations,  can  be  viewed  as  a lattice  whose  partial 
ordering  denotes  approximation,  and  that  this  lattice  can  be 
completed  by  permitting  infinite  programs,  including  the 
"unwindings"  of  iterative  and  recursive  programs.  We  have 
formulated  both  the  direct  and  continuation  semant  cs  of  this 
"domain  of  flow  diagrams,"  and  have  explored  their  properties. 

The  most  important  of  these  properties  is  that  flow  diagrams 

can  be  translated  into  a succession  of  increasingly  "lower-level" 


to  continuation  (but  not  direct)  semantics.  We  have  also  shown 
that  continuation  semantics  properly  subsumes  direct  semantics. 
Reference  2.6.3. 


\ 


2.4  The  use  of  transition  diagrams  as  a tool  for  structured 
programming  has  been  investigated.  The  basic  method  is  to 
represent  all  relevant  states  of  knowledge  about  the  state  of 
the  computation  as  nodes  labelled  with  assertions,  to  represent 
each  operation  as  an  arc  from  its  precondition  to  its  post 
condition,  and  to  represent  each  test  as  a complementary  pair 
of  arcs.  The  resulting  transition  diagram  is  easily  translated 
into  a program  using  goto  operations.  This  methodology  permits 
the  systematic  construction  of  useful  programs  which  are  difficult 
to  impossible  to  construct  with  more  conventional  methods.  It 
suggests  that  the  hallmark  of  an  intelligible  transition  diagram 
or  flow  chart  is  not  its  structural  simplicity,  but  rather  the 
simplicity  of  its  assertions.  No  reference. 

2.5  A variety  of  concepts  and  notations  have  been  devised  to 
facilitate  reasoning  about  arrays.  These  include: 

(a)  Diagrammatic  expressions  denoting  intervals  of  sub- 
scripts and  partition  relationships  among  such  intervals. 

(b)  Pointwise  extension  of  array  values  and  relations. 

(c)  The  generalization  of  the  concept  of  ordering  to 
arbitrary  binary  relations  between  array  elements. 

(d)  A variety  of  equivalence  relations  between  array  values 
to  be  viewed  as  a monoid,  or  an  associative  monoid,  under 
concatenation . 

1-7 


Examples  such  as  binary  search  and  various  sorting  algorithms 
show  that  the  use  of  these  notations  can  provide  an  order-of- 
magnitude  improvement  in  the  intelligibility  of  assertions  about 
arrays.  No  references. 


2.6  References  - PROGRAMMING  LANGUAGES 

2.6.1.  Reynolds,  J.  C. , Towards  a Theory  of  Type  Structures." 
(Section  4 of  this  report.) 

2.6.2.  Reynolds,  J.  C. , "User-Defined  Types  and  Procedural 
Data  Structures  as  Complimentary  Approaches  to  Data 
Abstraction. " 

(Section  3 of  this  report.) 

2.6.3.  Reynolds,  J.  C. , "Semantics  of  the  Domain  of  Flow 
Diagrams . " 

(Section  2 of  this  report.) 

2.6.4  Reynolds,  J.  C. , "Reasoning  about  Arrays." 

(Section  8 of  this  report.) 
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3.  SYSTEMS  STUDIES 


Robert  G.  Sargent,  Principal  Investigator 

The  system  research  performed  under  this  contract  will  be 
discussed  by  projects. 

3.1  The  development  of  a SIMSCRIPT  II. 5 simulation  model  of  the 
revised  Air  Force  Military  Personnel  Center  (AFMPC)  Initial 
Operational  Capability  (IOC)  Microfilm  System  was  completed  and 
the  proposed  system  evaluated  with  the  model  during  this  contract. 

A SIMSCRIPT  II. 5 model  operational  on  RADC's  computer  was 
delivered  to  RADC.  A RADC  Interim  Report,  RADC-TR-75-23 , entitled 
"A  Discrete  Simulation  Model  of  the  Revised  AFMPC  IOC  Microform 
System"  (3.5.1.)  describes  the  model.  A paper  (3.5.2.)  on  the 
project  was  given  at  the  1976  Summer  Computer  Simulation  Conference 
and  is  contained  in  the  Conference's  Proceedings. 

3.2  The  largest  effort  during  this  contract  was  evaluating 
RADCOLS,  Rome  Air  Development  Center's  On  Line  Simulator, 
developed  for  RADC  by  the  Computer  Science  Corporation  (CSC)  under 
contract  F30602-74-C-0281 . RADCOLS  is  a simulation  model  of  the 
Honeywell  Information  System  (HIS)  600/6000  computers  and  GCOS 
Operating  System.  An  error  was  found  in  the  model  and  this  was 
corrected  by  CSC.  During  this  correction  period,  RADC  upgraded 
their  computer  to  a HIS  6000  system,  a newer  GCOS  system,  and  a 
later  version  of  the  SIMSCRIPT  II. 5 compiler.  Under  this  new 
combination  the  model  would  not  execute  or  compile.  After 
considerable  evaluation  and  testing,  an  error  was  found  in  the 


SIMSCRIPT  II. 5 compiler  that  occurred  only  when  it  was  used  on 
the  HIS  6000  computers.  CACI  (the  company  that  developed  and 
owns  SIMSCRIPT  II. 5)  corrected  the  error  under  a new  Release 
for  RADC.  RADCOLS  will  now  compile  and  execute  but  then  fails 
after  it  runs  for  a period  of  time.  The  reason  is  currently 
unknown . 


3.3  A report  (3.5.3.)  "Statistical  Analysis  of  Simulation  Output 
Data"  is  in  volume  3 of  this  report.  It  is  a tutorial  on  the 
current  statistical  methods  of  analyzing  simulation  output  data 
and  it  contains  recommendations  when  to  use  specific  methods. 


3.4  Two  additional  activities  were  performed  for  RADC.  An  effort  j 

was  begun  to  understand  the  transaction  processing  system  of  the  j 

Honeywell  Information  System  in  order  to  model  it  in  order  to 

k 

determine  better  operating  rules  for  this  processor  for  specific 
workloads.  A brief  report  (3.5.4.)  on  transaction  processing 
systems  is  being  submitted.  The  other  activity  was  interacting 
with  RADC  personnel  on  modeling  and  testing  methodology  for 
system  design  and  system  evaluation. 


I 3.5  References  - SYSTEMS  STUDIES 

[ 3.5.1.  Trehan,  Vi jay  and  Sargent,  Robert  G.,  "A  Discrete 

. Simulation  Model  of  the  Revised  AFMPC  IOC  Microform  Svstem," 

RADC-TR-75- 23  Interim  Report,  February,  1975,  AD  # 007776 

3.5.2.  Trehan,  Vijay  and  Sargent,  Robert  G. , "A  Simulation 
Model  of  the  Air  Force  Military  Personnel  Center  (AFMPC) 
Initial  Operating  Capability  (IOC)  Microform  System," 
Proceedings  of  the  1976  Summer  Computer  Simulation 
Conference.  (Not  published  in  this  report.) 

I 
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3.5.3.  Sargent,  Robert  G. , "Statistical  Analysis  of 
Simulation  Output  Data,"  Department  of  Industrial  Engineer- 
ing and  Operations  Research  Report,  Syracuse  University, 
January  1977. 

(Section  16  of  this  report.) 

3.5.4.  Wood,  Daniel  and  Sargent,  Robert  G. , "An  Intro- 
duction to  Transaction  Processing  Systems,"  Department  of 
Industrial  Engineering  and  Operations  Research  Report, 
Syracuse  University,  January  1977. 

(Section  5 of  this  report.) 
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4.  MODELLING  AND  PERFORMANCE  EVALUATION  OF  GDMS 
Amrit  L.  Goel,  Principal  Investigator 

The  following  is  a summary  of  the  research  work  pursued  during  the 

■ 

contract  period.  Details  of  this  work  are  given  In  the  various  technical 
reports. 

4.1  An  Abstract  Formulation  of  File  Organizations 

The  purpose  of  this  activity  was  to  develop  a rigorous  framework  for 
describing  various  file  organizations  and  operations  on  files.  Towards 
this  objective,  we  first  define  various  terms  pertinent  to  the  description 
of  file  organizations  and  then  present  a description  of  sequential,  index 
sequential  and  hash  files.  Various  operations  on  these  files  are  also 
discussed.  Details  are  given  in  the  report  entitled  File  Organization  ' 

Concepts  by  Y.  Liu  and  A.  L.  Goel. 

4.2  Concurrency  in  Hashed  File  Access 

In  this  part  of  the  research  we  developed  and  studied  a nev/  technique. 

Concurrent  Hashed  Overflow  (CHO) , for  improving  the  performance  of  hashed 
file  systems  in  terms  of  both  access  counts  and  storage  efficiency.  The 
technique  involves  the  exploitation  of  the  ability  of  many  existing 
computer  systems  to  access  more  than  one  unit  of  data  concurrently. 

Algorithms  implementing  CHO  are  presented  and  an  analytical  model  describing 
its  performance  is  developed.  The  problem  of  optimizing  the  performance 
of  a CHO  file  is  formulated  as  a dynamic  programming  prof  lem  and  is  solved 
numerically.  Tables  are  presented  giving  dynamic  programming  optimum  stage 
allocations  and  next  stage  state.  From  these  tables  optimum  CHO  designs 
may  be  easily  obtained. 
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A paper  based  on  this  work  was  presented  at  the  IFIP-74  Congress  in 
Stockholm.  Details  are  given  in  the  report  entitled  Concurrency  in  Hashed 
File  Access  by  L.  Groner  and  A.  L.  Goel. 

4.3  Cascade  Hash  File  Organization  for  Disk  Files 
This  file  organization  was  developed  to  reduce  the  processing  time  for 

hash  files  stored  on  disks.  It  is  a refinement  of  hashing  and  guarantees 
that  all  the  probes  after  the  first  one  are  effectively  sequential  probes. 

Therefore  the  processing  time  is  reduced.  Moreover,  for  the  same  average 
processing  time,  a higher  load  factor  may  be  used  so  that  less  storage 
overhead  is  required  by  the  hash  file.  With  a slight  variation,  it  is 
possible  to  do  the  probes  in  parallel  to  reduce  the  processing  time  further. 

In  the  report  entitled  Cascade  Hashing  by  Y.  Liu  and  A.  L.  Goel,  we  describe 
this  file  organization  in  detail,  formulate  the  optimization  problem  for 
optimal  design,  discuss  the  solution  strategy  and  finally  obtain  the  optimal 
designs  for  implementation. 

4.4  Probabilistic  Models  for  Processing  Times  on  Index  Sequential 
and  Other  Files 

The  objective  of  this  research  activity  was  to  develop  and  Illustrate 
the  use  of  probabilistic  models  for  times  spent  in  various  operations  on 
index  sequential  and  other  simpler  files.  First  we  describe  various 
criteria  for  evaluating  the  performance  of  a file  organization  and  discuss 
the  problem  of  tackling  variability  in  performance.  The  basic  models,  using 
a probabilistic  approach,  are  then  developed  for  read,  add,  update  and  delete 
operations  on  an  index  sequential  file.  Based  on  these  models,  expressions 
are  developed  for  processing  times  for  sequential  and  direct  files.  Also 
discussed  are  models  for  some  special  cases. 
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The  above  models  are  not  amenable  to  analysis  by  conventional  statistical 


procedures.  We,  therefore,  investigate  various  methods  for  numerical  trans- 
formations of  random  variables,  and  choose  the  moments  method  for  this  problem. 
This  method  permits  us  to  handle  discrete,  continuous  and  mixed  distributions 
and  is  computationally  manageable.  The  use  of  the  models  is  described  via 
numerical  examples.  This  work  is  described  in  the  report  entitled  Evaluation 
Models  for  Index  Sequential  Files  by  A.  L.  Goel  and  Y.  Liu. 


4.5  References  - MODELLING  AND  PERFORMANCE  EVALUATION  OF  GDMS 

4.5.1.  Goel,  A.  L.  and  Liu,  Y. , "Evaluation  Models  for  Index  Sequential 
Files." 

(Section  9 of  this  report.) 

4.5.2.  Liu,  Y.  and  Goel,  A.  L.,  "File  Organization  Concepts." 

(Section  10  of  this  report.) 
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(Section  11  of  this  report.) 
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SEMANTICS  OF  THE  DOMAIN  OF  FLOW  DIAGRAMS 

John  C.  Reynolds 

Syracuse  University,  Syracuse,  New  York 

ABSTRACT  A domain  of  flow  diagrams  similar  to  that  proposed  by  Scott,  a 
domain  of  linear  flow  diagrams  proposed  by  Goguen  et  al,  a domain  of 
decision  table  diagrams  Involving  Inflnltary  branching,  and  a domain 
of  processes  based  on  the  Ideas  of  Milner  and  Beklc  are  each  provided 
with  a direct  semantics,  closely  related  to  partial-function  semantics, 
and  a continuation  semantics  similar  to  that  developed  by  Morris  and 
Wadsworth.  It  Is  shown  that  there  are  a variety  of  meaning-preserving 
continuous  functions  among  these  language-llke  domains,  that  every  direct 
semantics  possesses  an  "equivalent"  continuation  semantics,  and  that 
there  Is  a particular  continuation  semantics  which  always  gives  distinct 
meanings  to  distinct  processes.  The  proofs  utilize  the  algebraic  methods 
of  Goguen  et  al,  which  are  extended  to  continuous  algebras  with  operations 
whose  arguments  can  be  Indexed  by  Infinite  sets  or  even  domains. 

KEY  WORDS  AND  PHRASES  flow  diagrams,  lattices,  domains,  decision  tables, 
processes,  direct  semantics,  partial-function  semantics,  continuations, 
equivalence,  algebraic  semantics. 
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Introduction 


Scott^^^  has  shown  that  a simple  language  of  flow  diagrams,  in  which 
primitive  instructions  are  combined  by  composition  and  conditional  operators, 
can  be  embedded  in  a complete  lattice  containing  infinite  diagrams  which 

include  expansions  of  loops  and  recursions.  Goguen,  Thatcher,  Wagner,  and 

(2)  . . . . . 

Wright  have  shown  that  this  lattice  can  be  viewed  as  an  initial  algebra, 

(3) 

so  that  algebraic  methods  can  be  used  to  define  and  relate  it  semantics. 

They  have  also  proposed  a distinct  algebra  of  "linear"  flow  diagrams  with  a 
more  limited  form  of  composition  operator. 

In  this  paper  we  will  consider  both  kinds  of  flow  diagram,  as  well  as 
a domain  of  decision  table  diagrams,  involving  infinitary  branching,  and  a 
domain  of  processes , suggested  by  the  ideas  of  Milner^^^  and  Bekic.^^*^^ 

For  each  of  these  "languages",  we  will  define  a direct  semantics,  similar  to 
the  partial- function  semantics  used  in  the  theory  of  schemas,  and  a continuation 
semantics,  similar  to  that  developed  by  Morris^^^  and,  Wadsworth. We  will 
exhibit  a variety  of  meaning-preserving  functions  among  these  languages. 

We  will  also  show  that  every  direct  semantics  possesses  an  "equivalent" 
continuation  semantics,  and  that  there  is  a particular  continuation  semantics 
which  always  gives  distinct  meanings  to  distinct  processes. 

Our  proofs  will  utilize  and  illustrate  the  algebraic  methods  of  Goguen 
et  al.  To  facilitate  the  treatment  of  decision  table  diagrams  and  processes, 
we  will  show  that  these  methods  can  be  extended  to  continuous  algebras  with 
operations  whose  arguments  can  be  indexed  by  infinite  sets  or  even  domains. 
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Domulna  nnd  Predomalha 

Our  starting  point  la  the  ao-caJled  "lattice-theoretic  approach"  to  the 

(7  8) 

theory  of  computation,  originally  developed  by  Scott.  ' ' The  heart  of  this 
approach  Is  the  assumption  that  domains  of  data  can  be  partially  ordered  by  a 
relationship  E of  approximation,  in  terms  of  which  one  can  formulate  a 
completeness  property  satisfied  by  the  domains,  and  a continuity  property 
satisfied  by  meaningful  functions  between  domains.  In  Scott's  own  work,^^*^*®^ 
the  completeness  property  Is  the  existence  of  least  upper  bounds  for  all  subsets 
of  a domain,  so  that  a domain  Is  a complete  lattice.  However,  other  authors 
have  worked  with  a variety  of  weaker  completeness  properties  such  as  the 
existence  of  least  upper  bounds  for  directed  sets. 

After  considerable  experimentation,  we  have  decided  to  work  within  the 
framework  of  one  of  the  weaker  completeness  properties.  The  use  of  complete 
lattices  would  Introduce  so-called  "overdefined"  domain  elements  which  do  not 
possess  any  obvious  computational  reality  and  which  preclude  the  simple 
formulation  of  several  Intuitively  reasonable  relationships,  particularly  the 
close  connection  between  direct  semantics  and  conventional  partial-function 
semantics . 

A subset  of  a partially  ordered  set  is  said  to  be  directed  Iff  It  contains 
an  upper  bound  for  each  of  Its  finite  subsets.  A predomain  Is  a partially 
ordered  set  In  which  every  directed  subset  X possesses  a least  upper  bound, 
written \Jx.  A domain  Is  a predomain  which  contains  a least  element,  written  l. 
A function  f from  a predomain  S to  a domain  D Is  continuous  iff  f(I_JX)  » 
XJ{f(x)  I X c X}  for  all  directed  subsets  X of  S.  A function  from  a domain  to 


I a domain  Is  strict  Iff  It  preserves  l. 
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There  are  n variety  of  ways  in  which  we  could  alter  these  basic  definitions 
with  only  minor  changes  in  the  ensuing  development.  We  might  use  chains  or 
countable  chains  instead  of  directed  sets,  or  we  might  impose  various  topological 
restraints  on  domains,  such  as  lattice  continuity,  algebracity,  or  the  existence 
of  countable  bases.  But  the  above  definitions  seem  to  provide  the  simplest 
adequate  framework  for  our  results. 

In  the  terminology  of  Reference  2,  our  domains  are  strict  A-complete  posets, 
and  our  continuous  functions  are  A-continuous . Perhaps  the  use  of  Scott's 
own  term  "domain"  with  a different  definition  is  presumptuous,  but  we  want  to 
invoke  the  connotations  of  Scott's  terminology. 

The  relatively  unfeimiliar  concept  of  a predomain  will  play  a central  role  in 

our  development.  An  interesting  portion  of  the  lattice-theoretic  approach 

i . .... 

extends  to  predoraains,  and  they  are  useful  intermediaries  in  the  construction  of 

* domains.  Most  important,  the  concept  includes  both  domains  and  ordinary  sets, 

which  we  will  consider  to  be  predomains  partially. ordered  by  their  identity 

' relations.  The  result  is  a significant  unification.  For  example,  in  defining 

semantics  we  will  use  an  unspecified  predomain  S of  states.  In  conventional 

applications  S will  be  an  ordinary  set,  but  the  validity  of  Propositions  7 and  8 

will  require  the  use  of  an  S which  is  a domain. 

For  a predomain  S and  a domain  D,  we  write  S ->  D to  denote  the  set  of 

continuous  functions  from  S to  D,  partially  ordered  by  f C g iff  (Vx  c S) 

f(x)  £ g(x).  It  can  be  sliown  that  S D is  always  a domain,  in  which 

I I ^ ^ directed  F £ S D,  and  Ig^j^(x)  = 1^. 

Wlien  S is  a domain,  S D is  the  usual  domain  of  continuous  functions.  At  the 

other  extreme,  when  S is  a set  (partially  ordered  by  its  identity  relation),  S •+  D 

I is  the  domain  of  all  functions  from  S to  D. 

f 


For  a predomain  S,  we  write  to  denote  the  domain  formed  by  adding*  a 
new  least  element  to  S,  l.e. , the  disjoint  union  {x)  u S,  partially  ordered  by 
xEyirr  x = lor  (xeS  and  y c S and  x !E„  y).  Wlien  S and  S'  are  Kcta,  there 
is  an  obvious  isomorphism  between  S and  the  domain  of  partial  functions 

from  S to  s',  partially  ordered  by  the  subset  relation  between  the.  graphs  of  the 
partial  functions. 

We  write  Bool  for  the  predomain  {true,  false}.  Let  S,  S',  S"  be  predomains, 
D,  D',  D"  be  domains,  e c S f e S'  -»■  S^,  g e S"  -*■  D,  h e D D', 

1 £ D'  -*■  D",  and  q e S (S  -»•  S“) . Let  p be  a dtrict  function  in  D D'. 

We  define  the  expressions: 

= Ax.  X e D D 

h-g  E As".  hCgCs"))  e S"  D' 

ext(g)  = Ax",  if  x"  = i then  i else  g(x")  e S^  -»•  D 

JpHAs.seS-^-S 
o X 

g*f  = ext(g)*f  e S'  D 


condjj  E Ap.  Ax^.  Ax^. 


if  P 


E Boolj^  -»  (D  (D  D)) 


Each  of  these  expressions  is  continuous  in  all  variables.  The  reader  may 

verify  that 

h-Ip  = Ip.-h  = h 

(i*h)*g  = i* (h*g) 

ext(Jg)  = Ig^ 

e*Jg  •=  ^ 

(B*f)*e  = E^(f*e) 

As.  (E*(q(s)))(s)  = q(B)(s)) 

condg,._^p(p,  Cj^,  R2>(s")  = condp(p,  Ej(s"),  C2(s")) 
p(cond  (p,  X.,  x^))  condjj,(p,  p(Xj^),  pCx^)) 


As  Illustrated  by  the  last  two  equations,  we  will  often  write  f(x, x ) 

1 n 

for  f(x, ) ...  (x  ). 

1 n 

Note  that,  under  the  isomorphism  between  S and  the  domain  of  partial 

functions  from  a set  S to  a set  S',  the  composition  operator  * mirrors  the 
usual  composition  of  partial  functions. 

For  predomains  and  $2,  we  write  x $2  to  denote  the  predomain 
{<x^,  X2>  I Xj^  £ and  X2  E S2},  partially  ordered  by  <Xj^,  X2>  £ <yj|^,  ^2^ 

Xj^  E.  yj^  and  X2  5 y2.  When  both  and  S2  are  domains,  x $2  is  a domain 
with  the  least  element  <1,  !>. 

For  predomains  and  $2,  we  write  + S2  to  denote  the  domain 

{j.}  u {<1,  Xj^>  I Xj^  e u {<2,  X2>  ] X2  e S2},  partially  ordered  by  x £ y 

iff  x = i or  (x  = <i,  x'>  and  y = <1,  y'>  and  x'  y').  This  is  equivalent 

to  defining  ^2  “ ® ^2^1*  ® denotes  a conventional  disjoint  union 

of  sets  (with  the  obvious  partial  ordering) . 

We  will  need  to  generalize  this  kind  of  sum  to  an  iterative  construct. 

Suppose  OP  is  a set  and,  for  each  a e OP,  S is  a predomain.  We  write  ^ S 

aeOP 

to  denote  the  domain  {x}  u {<a,  x'>  | o e OP  and  x'  e S^},  partially  ordered  by 

x E y iff  X = 1 or  (x  = <0,  x'>  and  y = <a,  y'>  and  x'E-  y'). 

i>a 

When  their  operands  are  domains,  + and  \ denote  the  usual  notion  of  a 
separated  sum  of  domains. 

If  f e S D'  for  each  0 e OP,  we  write  / f to  denote  the  function 
° ° oeOP  ° 

g € i ^ S)->D'  such  that  g(x)  = x and  g(<a,  x'>)  = f^(x  ). 

oeOP  ° 


Algebras  and  Uomomorphlsms 

We  will  use  a notion  of  algebra  which  la  similar  to  the  continuous  algebras 

(2) 

of  Goguen  et  al.  However,  we  will  generalize  this  notion  to  permit  operations 
whose  arguments  can  be  Indexed  by  arbitrary,  perhaps  Infinite,  predoroains. 

On  the  other  hand,  we  will  not  explore  the  many-sorted  case  treated  in  Reference 
2,  since  the  conventional  one-sorted  case  Is  notatlonally  simpler  and  adequate 
for  our  needs. 

A signature  E consists  of  a set  OP  of  operators  and  a mapping  rank  which 

assigns  a predomain  to  each  operator  In  OP.  For  a predomain  S,  we  write  E 

to  denote  {o  | o e OP  and  rank(a)  **  S}.  We  will  normally  specify  a signature 

by  listing  each  nonempty  Eg,  A E-algebra  EX  consists  of  a domain  X,  called  the 

carrier  of  EX,  and  an  interpretation  which  assigns  to  each  o e Eg  an  operation 

EX  e (S  ■>  X)  -*•  X. 

0 

In  this  formulation,  conventional  algebraic  operations  such  as  constant, 
unary,  and  binary  operations  are  provided  by  the  ranks  S = {},  (l),  {1,  2},  ...  . 
Strictly  speaking,  we  should  write 


J:Xjj(<>) 

EX  (<x,>) 

O 1 

EX^(<x^,  x^>) 


instead  of  the 


conventional  notation 


EX^(x.  ) 
a 1 

EX^(x^,  Xg) 


where  <Xj^,  ...  , x^>  denotes  the  function  from  {1,  ...  , n}  to  X which  maps  i 
into  x^.  However,  we  will  frequently  use  the  less  cumbersome  conventional 
notation.  Since  we  regard  EX^(Xj^,  x^)  as  an  abbreviation  for  EX^(xj^)(Xjj) , 
this  is  tantamount  to  identifying 

({}  ->  X)  X with  X 
({1}  X)  ->  X with  X ->■  X 

<{1,2}  X)  X with  X (X  -*■  X). 


W 


Algebras  will  usually  be  named  by  giving  their  signature  and  carrier. 

One  must  remember  however,  that  two  algebras  with  the  same  signature  and  carrier 
can  still  have  different  interpretations.  We  will  use  E for  an  arbitrary 
signature,  aind  A,  f,  and  A for  specific  signatures.  Similarly,  we  will  use 
X (with  occasional  superscripts)  for  an  arbitrary  carrier  and  other  symbols  for 
specific  carriers. 

Let  EX  and  EX'  be  E-algebras  and  p be  a strict  continuous  function 
from  X to  X* . If,  for  all  a e Eg  and^e  S-^X,  p satisfies  the  homomorphic  equation 
p(EX  (x))  = EX'Cp’x),  then  p is  said  to  be  a homomorphism  from  EX  EX'.  We 
write  EX  EX'  for  the  set  of  such  homomorphisms.  When  S = {1,  ...  , n},  the 
Identifications  given  above  reduce  the  homomorphic  equation  to  the  conventional 

form  p(EX  (x  , ...  , x ))  = EX'(p(x  ),  ...  , p(x  )). 

0 1 n o 1 n 

As  usual,  algebras  and  homomorphisms  form  a category,  i.e., 
e EX  EX 

p e EX  -»■  EX'  and  p'  e EX'  EX" 

Implies  p'*p  e EX  ->■  EX". 

An  algebra  EX  is  said  to  be  Initial  (key)  if,  for  each  algebra  EX'  with 
the  same  signature,  there  is  exactly  one  (at  most  one)  homomorphism  from  EX  to  EX'. 
As  shown  in  Reference  2,  all  initial  algebras  V7ith  the  same  signature  are 
Isomorphic,  so  that  we  can  speak  of  the  initial  algebra  for  E.  Wc  denote  this 
algebra  by  ElnE,  its  carrier  by  InE , and  the  unique  homomorphism  from  it  to  EX' 

^Ex'- 

Although  these  definitions  of  algebras  and  homomorphisms  are  unorthodox, 
one  can  still  prove  the  following  theorem,  which  is  the  sine  qua  non  of 
algebraic  semantics: 


I 

I 
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Theorem  1 There  Is  an  Initial  algebra  ElnT  for  any  signature  Z. 

Proof:  We  will  first  construct  EInZ  and  then  sliow  that  It  possess  a unique 
homomorphism  to  any  E-algebrai  The  carrier  la  obtained  by  using  Scott's 
Inverse  limit  construction  to  obtain  a domain  satisfying  the  Isomorphism 


InE  Qi  I (rank(o)  InE)  (1) 

ocOP 

where  OP  and  rank  are  the  operator  set  and  rank-mapping  of  the  signature  £. 

The  inverse  limit  construction  Is  described  In  detail  in  (9)  and,  more  abstractly, 

in  (15).  Although  these  descriptions  use  the  framework  of  complete  lattices, 

the  construction  carries  over  without  significant  change  to  the  present  definitions. 

In  general,  an  Isomorphism  such  as  (1)  can  have  many  solutions.  The 

particular  solution  InE  produced  by  the  Inverse  limit  construction  (starting  with 

the  one-point  domain  as  Dq)  Is  uniquely  characterized  within  an  isomorphism  by 

(9) 

the  following  property:  The  Identity  function.  Ij.^j.  is  the  least  solution  of 


the  equation 


1 “ I (^x.  <0,  l*x>) 
oeOP 


Here  the  parenthesized  expression  denotes  a function  from  rank(o)  InZ  to 

^ (rank(o)  InZ).  Strictly  speaking,  (2)  should  be  written  as 
oeOP 

1 A ' 

1 *=  ♦ * ( X l*x>))  ‘ ♦ , 

oeOP 

where  ♦ is  the  Isomorphic  function  from  the  left  side  of  (1)  to  the  right  side, 
but  we  will  adopt  the  practice  of  eliding  4>  and  its  inverse.  , 

To  make  InZ  Into  a E-algebra,  We  provide  the  following  interpretation  of 
the  operators:  For  all  o e Z_  and  x c S InZ,  EInZ  (x)  = <a,  x>. 

Now,  suppose  EX  is  any  Z-algebra.  Let  Iq,  1^^,  ...  e InZ  InZ  and  Pq, 


c InE  -♦  X be  the  functions  such  that 
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'll 


^0  ” 


n+1 


V* 

I (Xx.  <a,  I •x>) 


oeOP 


Wq  “ 


'ttfl 


I*  (Xx.  EX  (n  -x))  . 
“ — on—' 


oeOP 


By  Scott's  least  fixed  point  theorem,  the  I 's  and  p 's  are  directed  sequences 

such  that  U ^ the  least  solution  of  equation  (2) , and  Is  therefore  the 
n*®o 

00 

Identity  function  for  InE,  while  T T p Is  the  least  solution  of 

n"o 

p = X (Xx.  EX  (p*x))  . 
oeOP  ® 

This  equation  shows  that  p satisfies  p(EInE  (x))  = p(<o,  x>)  =»  EX  (p*x)  for  each 

a . o 

r* 

operator  o,  while  the  definition  of  2,  insures  that  p is  strict.  Thus  p e ElnE  EX. 

On  the  other  hand,  suppose  p e ElnE  ->■  EX.  We  show  that  l>y 

Induction  on  n.  For  n = 0 we  have  p*i  = i,  since  p(i)  = i.  The  Induction  step  is 


p*I  , = I (Xx.  p(<o,  I •x>)) 
oeOP 

= I (Xx.  p(EInE  (I  -x))) 
oeOP 

= I*  (Xx.  EX^(p-I  -x)) 
oeOP  ° 

I (Xx.  EX  (p  ‘x)) 

**  , o n 


oeOP  ” 

where  the  first  line  requires  the  strictness  of  p.  B t then  the  continuity 

«0  00  00 

of  composition  gives  p = p*I  •=  P‘(tJ  I ) = O P‘^  “ LT  P “ M*  0 

inL  n n n 


n*o 


n=o 


n=o 


2-10 
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When  every  operator  has  a rank  of  the  form  (1 n}.  Theorem  1 

coincides  with  Corollary  4.10  of  Reference  2,  and  despite  its  very  different 
construction,  £In£  is  isomorphic  to  the  Initial  algebra  CT^.  of  (2). 

The  idea  behind  algebraic  semantics  Is  to  regard  a language  as  an  initial 
algebra  and  its  semantic  function,  l.e.,  the  function  which  maps  each  element  of 
the  language  into  its  meaning,  as  the  homomorphism  into  some  target  algebra  with 
the  same  signature.  Indeed,  since  this  homomorphism  is  unique,  the  semantic 
function  is  fixed  by  the  specification  of  the  target  algebra  itself. 

However,  in  the  framework  of  continuous  algebras,  an  initial  algebra  is 
far  richer  than  a conventional  word  algebra  - our  "languages"  contain  partially  ! 

defined  and  (most  mysteriously)  infinite  elements.  But  the  imposition  of 

strictness  and  continuity  upon  homomorphisms  forces  these  elements  to  behave 
themselves,  while  their  presence  provides  a profound  capability  explored  by 
Scott:  Concepts  such  as  iteration  and  recursion  can  be  viewed  as  purely 
syntactic  mechanisms  which  permit  finite  language  elements  to  abbreviate  i 


r\tr^ao 


i 

I 


I 

i 

I 

I 

t 

! 


1 

I 

P 


s 

I 


i 


I 


The  Direct  Semantics  of  General  Flow  PlaRrams 

We  now  embark  on  a Cook's  tour  of  several  closely  related  languages  and 
semantics.  The  Initial  view  Is  Informal;  we  provide  a reasonable  concrete 
syntax  for  the  Initial  algebras,  and  describe  semantics  In  the  style  of  Scott 
and  Strachey,  which,  as  Illustrated  In  Section  3.2  of  Reference  2,  Is 

equivalent  to  substituting  target  algebra  operations  Into  the  homomorphic 
equations. 

Let  F be  some  set  of  primitive  Instructions  and  B be  some  set  of  Boolean 
expressions.  Then  the  language  of  general  flow  diagrams  Is  the  Initial  algebra 
ninO  for  the  signature  R such  that 

= {1}  u F,  2}  “ ^ ® 

Using  the  concrete  syntax  provided  by  Scott,  we  write: 


I 

for 

fllnfij 

f 

for 

RlnR^ 

for 

Rlnfl . (x^ , 

X2) 

b -»■  Xj^,  X2 

for 

OlnQ.  (x-  , 
b X 

This  Initial  algebra  Is  Isomorphic  to  CT  , In  Section  5.2,  part  II,  of  Reference  2. 

I* 

Except  for  the  omission  of  overdefined  elements,  it  is  similar  to  Scott's  lattice 
of  flow  diagrams. (Albeit  with  other  minor  differences:  Our  formulation  causes 
us  to  distinguish  i;i  from  X,  and  to  disallow  elements  of  the  form  X x^,  , ^2.) 

Let  S be  some  predomain  of  states . Then  the  direct  semantics  of  general 
flow  diagrams  is  provided  by  the  semantic  function  p „ e InJl  -*■  H,  into  the 
"semantic  domain"  11  = S -*■  S^,  such  that: 
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tlH'  2'  ^nH'  1' 


Pjjj^(b  ■*■  x^,  x^)  “ As.  cond  (lg(b,  s) , Ujjjj(Xj^,  s),  yjjH(x2» 


Here  ^ e F -►  H and  "G  e B ->■  (S  -♦•  Bool^)  are  unspecified  functions  which  provide  the 

meaning  of  primitive  instructions  and  Boolean  expressions.  Informally,  these 

equations  can  be  regarded  as  a language  definition  in  the  style  of  Scott  and 

Strachey. But  from  the  algebraic  viewpoint,  they  are  simply  the 

homomorphic  equations  which  assert  that  is  the  unique  homomorphism  from 

ilH 

ninO  into  a certain  target  algebra  RH  with  carrier  H.  The  structure  of  target 
algebras  such  as  RH  will  be  given  more  abstractly  later. 

When  S is  a set,  H = S la  isomorphic  to  the  set  of  partial  functions 

from  S to  S,  and  * mirrors  the  usual  composition  of  partial  functions.  In  this 
case,  direct  semantics  reduces  to  the  usual  kind  of  partial-function  semantics 
encountered  in  the  treatment  of  schemas. 

On  the  other  hand,  our  direct  semantics  is  intentionally  more  restrictive 
than  the  semantics  suggested  by  Scott,  in  which  the  semantic  domain  is  S S 
for  an  unspecified  complete  lattice  S,  and  * is  replaced  by  conventional 
functional  composition.  Scott's  semantics  becomes  unnatural  when  one  does  not 
require to  be  strict.  For  example,  let  6 be  a flow  diagram  whose  meaning  is 
X,  presumably  a diagram  whose  execution  never  terminates.  Then  6;  f eoul.d  have  a 
different  meaning  than  X,  which  would  suggest  that  the  statement  following  a 
nonterminating  statement  could  affect  the  computation.  The  obvious  solution  is 
to  replace  S -►  S and  S -*■  Bool^  by  domains  of  strict  functions.  Our  direct 
semantics  is  basically  similar  to  imposing  this  strictness  requirement,  but  it 
emphasizes  that  X in  is  not  really  a "state". 
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Direct  semantics  Is  capable  of  describing  schema-llke  languages  Involving 
assignment  and  side-effect  free  expressions.  But  It  Is  Inadequate  for  a variety 
of  primitive  Instructions  occurring  in  real  programming  languages.  Let  6 be  a 


flow  diagram  whose  meaning  is  l (in  the  domain  S ->•  . Then  for  any  primitive 

Instruction  f,  the  meaning  p.„(f:  5)  of  f;  5 will  also  be  i.  (Note  that  In 

Wn 

contrast  to  the  previous  paragraph,  we  are  now  examining  the  effect  of  a 
primitive  Instruction  which  precedes  a non-termlnatlng  diagram  and  can  sensibly 
affect  the  computation.)  This  Is  clearly  Inadequate  to  accomodate  primitive 
instructions  such  as  stop  or  ^rlnt(n).  The  Introduction  of  such  Instructions 
precludes  the  assumption,  made  In  direct  semantics,  that  the  meaning  of  an 
Instruction  Is  a function  which  accepts  the  state  existing  immediately  prior 
to  execution  of  the  Instruction  and  produces  the  state  existing  Immediately  after 
execution  of  the  Instruction.  To  avoid  this  assumption,  we  turn  to 
continuation  semantics. 

The  Continuation  Semantics  of  General  Flow  Diagrams 

In  continuation  semantics,  originally  developed  by  Morris and  Wadsworth, 
the  meaning  of  an  instruction  (or  flow  diagram)  is  a function  which  accepts  the 
state  existing  immediately  prior  to  execution,  plus  an  additional  argument 
called  the  continuation,  and  produces  the  final  output  of  the  entire  program. 

! 

I 

5 
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The  continuation  which  is  provided  as  a second  argument  is  a function  from 
the  state  existing  after  instruction  execution  to  the  final  program  output, 
which  gives  the  semantics  of  the  "rest  of  the  computation"  to  be  performed  if 
the  current  instruction  "terminates  normally."  Thus  an  instruction  vjith  normal 
behavior  will  produce  Its  output  by  applying  the  continuation  to  the  slate 
following  execution.  But  an  "abnormal"  instruction  can  produce  the  final  output 
in  some  other  manner  - possibly  ignoring  the  continuation. 

Let  S again  be.  some  predomain  of  states,  and  let  0 be  some  domain  of  outputs , 
whose  least  element  i denotes  the  "output"  of  a non-terminating  computation. 

The  domain  of  continuations  is  C = S -*■  0,  and  the  semantic  domain  is 
W ^ C -*•  (S  -*■  0)  = C -»•  C.  (Somewhat  counterintuitively,  we  have  made  continuations 
the  first  argument  and  states  the  second  argument  of  the  meanings  of  flow  diagrams; 
this  vjill  eventually  simplify  our  semantic  equations.)  Then  the  continuation 
semantics  of  general  flow  diagrams  is  provided  by  the  semantic  function  c InJJ  -+■  W 
such  that: 

Pjjy(I)  = Ac.  As.  c(s) 

v„„(f)  =^(f) 

hjjy(b  -»■  Xj^,X2)  = Ac.  As.  condpC  ^(b,s) , c,  s) , hjjyCx^,  c,  s)) 

where  e F -»■  W and  e B (S  Bool^^)  are  unspecified  functions  providing  the 
semantics  of  primitive  instructions  and  Boolean  expressions. 

The  essence,  of  continuation  semantics  is  revealed  by  the;  third  equation. 
Intuitively,  to  execute  x^^;  X2  with  an  initial  state  s and  ,1  continuation  c, 
we  execute  x^  with  the.  state  s and  a continuation  Ac'.  hj^j^(x2,  c,  s')  which  picks 
up  the  state  s'  after  execution  of  and  then  executes  X2  with  s'  and  llie 
continuation  c,  which  in  turn  pick.s  up  the  state  after  ext. cut  ion  of'  X2  and  then 
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executes  the  rest  of  the  program.  But  more  generally,  the  equation  shows  that 
it  is  the  meaning  ^2^  which  determines  how  the  final  output  will  be 

affected  by  the  meaning  V‘jjy(x2)  of  X2,  which  in  turn  determines  how  the  final 
output  will  be  affected  by  the  "meaning  of  the  rest  of  the  program"  c. 

Further  insight  is  provided  by  a brief  digression  on  the  semantics  of 
some  "abnormal"  primitive  instructions.  To  handle  stop  e F,  we  can  take  0 = 
and  ^ (stop)  = Ac.  As.  s = Ac.  J^.  This  makes  it  clear  that  the  final  output 
caused  by  a stop  instruction  will  be  the  state  existing  Immediately  before  its 
execution,  regardless  of  the  rest  of  the  program. 

To  handle  intermediate  output  of  integers,  let  Int  be  the  set  of  integers, 
N be  some  set  of  Integer  expressions,  end'll  e N -»■  (S  Int^^)  be  a function 
giving  the  semantics  of  integer  expressions.  Let  0 be  a domain  satisfying  the 
isomorphism 

0 S + Int  X 0 

and  let 

S-  ext(Al  e Int.  P2(i»  c(s)))C^n,  s)) 

(stop)  = Ac.  As.  Pj^(s) 

where  p^  and  P2  are  the  obvious  injection  functions  from  S and  Int  x 0, 
respectively,  into  0.  The  elements  of  0 can  be  classified  into  three  distinct 
kinds  of  output: 

(1)  P2(ij^,  •••  , •••  )»  which  would  be  the  output  of  a 

program  which  prints  the  integers  1^^,  ...  , Ij^  and  then  terminates  in 
the  state  s. 

(2)  P2^^1*  ‘ ^2^^k’  would  be  the  output  of  a program 

which  prints  the  integers  i^^ ij^  and  then  runs  forever  without 

further  printing. 
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(3)  ***  ~ ° limit  point  In  thu  domain  U - which  would 

be  the  output  of  a program  which  prints  the  endless  sequence  of  integers 


i^ » ^2 • • • • • 


In  this  situation,  final  output  is  a misnomer,  since  a program  can  continue 
to  generate  output  forever.  A better  term  would  be  irreversible  output,  since 
the  semantics  Insures  that  the  rest  of  the  program  cannot  rescind  the  effect 
of  a print  instruction. 

Returning  to  general  flow  diagrams,  where  the  interpretation  of  primitive 
instructions  is  left  unspecified,  we  can  simplify  our  equations  for  by 
using  eta-reduction.  Specifically,  As,  c(s)  = c.  As*.  Pjjy(x2»  “ 

Pjjy(x^,  c),  and  As.  ...  , s)  = ...  ).  Thus 

= Ac.  c = 

p„^(f)  =^{f) 

-»■  x^.Xg)  = Ac.  As.  condQ{-g>(b,3),  Pjjy(xj^,c,s) , ^^^^(x^.c ,s ) ) 

Intriguingly,  the  order  of  composition  in  the  third  equation  is  the  reverse 
of  the  order  for  direct  semantics. 


Linear  Flow  Diagrams 

There  are  many  flow  diagrams  which  possess  the  same  meaning,  regardless 
of  the  choice  of  direct  or  continuation  semantics.  The  other  languages  we 
shall  consider  can  be  thought  of  as  successive  attempts  to  strip  away  this 
redundancy  and  approach  the  goal  of  canonicality , where  distinct  diagrams 
have  distinct  meanings.  Eventually,  it  will  become  clear  that  we  have  a 
succession  of  languages  with  meaning-preserving  mappings  from  each  language 
to  the  next,  where  the  final  language  (of  processes)  is  canonical  for 
continuation  semantics.  For  the  present  however,  this  image  is  only  meant 
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to  motivate  our  definitions,  and  no  attempt  will  be  made  to  prove  relationships 
between  languages  or  equivalences  within  a language. 

In  any  reasonable  semantics,  one  would  expect  the  meaning  of  general  flow 
diagrams  to  satisfy  the  following  equivalences: 

li  « xi 

(x^;  Xg);  Xj  “ x^j  (x^;  x^) 

(b  Xg);  x^  “ b (x^;  x^),  (xg;  x^) 

Intuitively  - neglecting  tmy  complications  which  might  be  caused  by  infinite 
diagrams  - these  equivalences  can  be  used  to  transform  any  flow  diagram  until 
every  left  operand  of  is  a primitive  instruction,  A flow  diagram  which 
meets  this  restriction  is  said  to  be  linear. 

(2l 

Following  Goguen  et  al,  we  can  formulate  linear  flow  diagrams  as  an 
initial  algebra  by  regarding  f;  x as  the  application  of  a unary  operator,  named 
by  f,  to  the  opertuid  x»  Thus  the  language  of  linear  flow  diagrams  is  the 
initial,  algebra  Mnh  for  the  signature  A such  that 

A^)  = {!),  A^j  -=  F,  ^{1,2}  “®* 

This  Initial  algebra  is  isomorphic  to  CTj,  in  Section  5.2,  part  I,  of  Reference  2. 
As  a concrete  syntax  we  write 


1 

for 

AlnAj^ 

£;  X 

for 

AlnAj(x) 

b -»•  Xj^,  x^ 

for 

AlnAj^Cxj^ 

This  notation  has  been  chosen  so  that  general  and  linear  flow  diagrams  with 
the  same  concrete  representation  should  have  the  same  meaning.  Intuitively, 
applying  this  relationship  to  the  forms  I,  f;  x,  and  b -*■  determines 

the  semantic  equations  for  linear  flow  diagrams. 


t 


'll 


Thus  direct  semantics  Is  provided  by  the  semantic  function  e InA  H 
such  that 

»*.■«>  - •'s 

x)  “ P^y(x)*^(f) 

*1**2^  “ (S(b,B).  ‘'ah 

while  continuation  semantics  is  provided  by  fe  InA  -»•  W such  that: 

x)  = ^ (f)*Mj^y(x) 

‘‘aw^'’  *1'*2^  " ^®*  condQ(2>(b,s),  p^j^(xj^,c,s),  p^y(x2,c,s)) 


? true 


“1 

true 


false 

X 


11 


'21 


false 


12 


22 


X 

X 


similarly,  either  side  of  the  second  equivalence  can  he  replaced  by 


D 


false  X 

x^2  J- 

*22  *22 

X X 


Essentially,  the  decision  DCxI  means  "Produce  a list  t of  the  current  value  of 
all  Boolean  expressions  in  B,  and  then  execute  the  table  entry  x(t)," 

V,w 

llie  "list"  t is  really  a function  in  the  domain  T = B Bool^.  Thus  if 
table  entries  belong  to  the  set  Inf  (which  is  going  to  be  the  language  of 
decision  table  diagrams),  then  the  decision  table  x itself  will  be  a function 
from  T to  Inf.  But  only  some  of  these  functions  are  reasonable. 

In  the  evaluation  of  any  compound  conditional  branching  operation,  for  a 
particular  value  of  b^,  either  b^  will  be  evaluated,  so  that  the  nontermination 
of  b will  imply  the  nontermination  of  the  entire  branching  operation,  or  b will 
not  be  evaluated,  so  that  the  outcome  will  be  independent  of  b^.  This  is 
reflected  by  the  fact  that  every  row  in  a decision  table  h;  3 either  the  form 
X y i or  the  form  x x x.  A similar  rule  holds  for  columns.  As  a consequencd, 
decision  tables  are  always  monotonic  functions  from  T to  Inf. 
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The  generalization  to  arbitrary  finite  B Is  straightforward.  More 
surprlslnglyi  we  can  even  permit  B to  be  Infinite.  The  only  qualification, 
which  is  typical  of  the  lattice-theoretic  approach,  is  that  decision  tables 
are  required  to  be  continuous,  rather  than  merely  monotonic,  functions  from 
T to  Inf.  Thus  the  decision  operator  D accepts  operands  which  belong  to 
T -»■  Inf,  i.e.,  it  is  an  operator  with  rank  T.  Although  such  an  operator 
goes  beyond  the  framework  of  conventional  algebra,  it  is  encompassed  by  our 
generalization  to  operators  whose  ranks  are  arbitrary  predomains. 

Of  course,  an  infinite  decision  table  cannot  be  explicitly  tabulated, 
but  it  can  still  be  described  by  functional  notation.  For  example,  the 
decision  table  diagrams  given  above,  when  generalized  to  an  arbitrary  B 
containing  b^^  and  b^,  can  be  represented  by 

D^Xt.  condj^j,(t(bj^) , condj.^^p(t(b2) , 
condjnfCtCbg  )»  ^21*  ^22^^^ 

and 

D^Xt.  condj^j,(t(bj^),  cond^^j.(t(b2) , x^^^,  x^g),  x^g)] 

However,  such  expressions  are  not  in  themselves  decision  table  diagrams, 
but  only  indirect  and  nonuniqUe  representations  of  such  diagrams. 

With  this  movitation,  we  can  give  a precise  definition.  The  language 
of  decision  table  diagrams  is  the  initial  algebra  flnf  for  the  signature  f 
such  that 


r.j  = {!},  = p,  fj  « {D}  . 


Direct  semantics  is  provided  by  the  semantic  function  e Inf  -*■  H 


such  that 

“ni"'  = •'s 

Pj.jj(D[xJ)  = Xs.  Pj.jjWXb.'i&Cb.s)),  s) 

In  the  last  equation,  the  function  Ab.lS’Cbjs)  e T denotes  the  "list"  of  the 
values  of  all  Boolean  expressions  in  the  state  s. 

For  continuation  semantics,  we  have  the  semantic  function  e Inf  W 


such  that 


Pj.y(f;  x)  = t^(f)*pj.y(x) 

Pj;y(D[x])  = Ac.  As.  Pj,^^WAb.'^(b,  s)),  c,  s) 

Admittedly,  we  are  stretching  a point  in  calling  decision  table  diagrams 
a language.  They  are  even  further  than  flow  diagrams  from  the  conventional 
finitary  concept  of  language.  But  they  still  have  the  essential  linguistic 
characteristic  of  being  iminterpreted:  They  make  no  commitment  to  a choice 
of  the  set  of  states,  nor  to  the  meaning  of  primitive  instructions  or  Boolean 
expressions,  nor  even  to  the  choice  between  direct  and  continuation  semantics. 


Processes 

There  are  two  important  equivalences  for  decision  table  diagrams. 


The  first. 


DCxt.  x3  = X , 


shows  that  a decision  is  redundant  if  all  of  its  table  entries  are  the  same. 


Tlic  second. 


D[At.  D[At'.  g(t,  t')]]  I)[At.  g(t,  t)J 


where  g c T -♦  (T  Inf),  shows  that,  when  the  entries  of  a decision  table  are 
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themselves  decisions,  the  inner  decisions  must  "go  the  same  vay"  as  the  outer 
one,  since  there  is  no  intervening  primitive  instruction  which  might  change 
the  state  of  the  computation. 


To  eliminate  this  kind  of  redundancy,  ve  will  define  a further  language 
in  which  decisions  and  primitive  instructions  are  required  to  alternate. 

More  precisely,  a decision  table  entry  will  always  have  the  form  I,  ori-, 
or  f;  D|[x3  where  is  a decision  table. 

To  obtain  an  algebraic  formulation,  we  regard  f;DtxJ  as  the  application 
of  a T-ary  operator,  named  by  f,  to  the  operand  x.  Then  table  entries  are 
the  initial  algebra  AlnA  for  the  signature  A such  that 

‘o  ' «>-  V' ' • 

As  a concrete  syntax,  we  write 

1 for  AlnA^ 

f;  DfxJ  for  AInA_(x)  , 

1 ♦*- 

which  suggests  the  relationship  between  oxir  new  language  and  the  language  of 
decision  table  diagrams. 

If  InA  is  the  domain  of  table  entries,  then  decision  tables  themselves 
belong  to  the  domain  T InA,  Which  we  will  call  Z.  From  equation  (1)  In  the 
proof  of  Theorem  1,  InA  satisfies  the  domain  isomorphism 

InA  X (rank(tT)  InA) 

oe{I}^F 

= I if  o = I then  ({}  InA)  else  (T  InA) 

oe{I)uF 

s 'j  if  0 = I then  {•}  else  Z 

OE{i)UF 

where  {•}  denotes  u one-element  domain.  But  the  right  side  is  easily  seen  to 
< be  isomorphic  to  {•}  + F x Z.  Thus  Z and  InA  satisfy 


r 


These  "domain  equations"  suggest  a close  connection  with  the  concept  of 


processes  developed  by  Milner^^^  and  Bekic,^^^^  which  in  fact  inspired  the 


language  described  here.  To  emphasize  this  connection  we  will  henceforth 
call  Z the  domain  of  processes  and  InA  the  domain  of  process  components. 
However,  it  should  be  noted  that  the  processes  of  Milner  and  Bekic  are  less 
syntactic  than  ours,  and  are  speeifieally  oriented  to  problems  of  concxirrent 
processing  which  are  not  considered  here. 

Intuitively,  the  process  z means  "For  the  current  state  s,  compute  a list 
t = lb. <?(b,s)  of  values  of  the  Boolean  expressions,  and  then  execute  the 
process  component  z(t)."  The  process  component  I means  "Do  nothing,"  while  the 
process  component  f;  D^zJ  means  "Execute  f and  then  execute  the  process  z." 

This  intuition  is  captured  in  direct  semantics  by  the  semantic  functions 


6_u  e Z ^ II  and  e InA  H such  that 
rn  AH 


= ^s.  p^jj{z(Xb.';6’(b,s)),  s) 


' •'S 


For  continuation  semantics,  the  semantic  fmetions  are  6^,^^  c Z V/  and 


p.,,  e liiA  V/  such  that 
AW 


= Ic.  As.  p^^(z(Ab. /J(b,s)),  c,  s) 


-py;» 

For  either  set  of  semantic  equations,  the  substitution  of  the  first 


equation  into  the  third  gives  a pair  of  homomorphic  equations  for  or  y 


'aw* 


We  have  introduced  the  subsidiary  functions  6 and  (whose  names  will  become 

1 H I W 


meaningful  later)  to  treat  the  domains  Z and  InA  more  symmetrically. 
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Nevertheless,  Z,  tuilike  InA|  is  hot  the  carrier  of  an  initial  algebra. 
This  anomaly  is  the  price  of  avoiding  many-sorted  algebras.  One  could  define 


Z and  ln&  as  the  carriers  of  a two-Borted  initial  algebra,  with  and 

(or  fi-u  and  g.„)  as  the  components  of  a two-sorted  homomorphism. 
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From  an  algebraic  viewpoint,  the  eight  lemguage  definitions  we  have  given 
are  tantamovmt  to  a specification  of  the  following  target  algebras: 


Language 

Direct  Semantics 

Continuation  Semantics 

General  flow  diagrams 

RH 

nw 

Linear  flow  diagrams 

AH 

AW 

Decision  table  diagrams 

TH 

rw 

Process  components 

AM 

AW 

Our  main  task  is  to  define  these  target  algebras  tnore  directly,  and  to 
investigate  relationships  among  them.  As  each  target  algebra  is  defined, 
it  will  become  apparent  that  the  corresponding  language  definition  is  a display 
of  the  equations  for  the  homomorphism  into  the  target  algebra  from  the  initial 
algebra  with  the  same  signature. 

We  will  begin  with  decision  table  diagrsims,  then  move  "forward”  to 
processes,  and  then  move  "backwards"  to  linear,  and  finally  general  flow  diagrams. 


Decision  table  dlgarams  are  the  initial  algebra  with  the  signature  r such 
that  = {!},  = F,  and  = {D}  , where  T *=  B ->■  Booi^^.  To  describe  their 

direct  semantics,  let  S be  some  predomain  of  states,  H = S S^,  e F H,  and 
Kg  B (S  Boolj^).  Then  the  target  algebra  TH  is  the  f -algebra  with  carrier 
H such  that 


rii^(h)  - h*c>r(f) 

THn  (h)  = \B.  h(Xb.??(b,  s),  s)  . 


f 


For  continuation  semantics,  let  S be  some  predomain  of  states,  0 be  some  domain 
of  outputs,  C = S->-0,  C,^c  T V,  and  c 'B  -*■  (S  -»■  BooJ.^) . Then  the 

target  algebra  rw  is  the  F-algebra  with  carrier  W such  that 

rw  =>  1 

* I C 

rw^(w)  = ^ (f)*w 

rWy^  (w)  = Xc.  Xs.  w(Xb.B(b,  s),  c,  s) 

■w  .v^ 

The  previously  given  semantic  equations  for  decision  table  diagrams  are  simply 

the  homomorphic  equations  for  the  unique  homomorphisms  e TlnF  -*  TH  and 

TH 

iij.y  c rinr_:»^  rw. 

We  can  now  establish  the  fundamental  relationship  between  direct  and 
continuation  semantics.  First  note  that  HI  is  actually  a family  of  T-algebras 
depending  upon  the  triple  <S,*^,2f>,  which  ve  will  call  a direct  interpretation. 
Similarly,  FW  is  actually  a family  depending  upon  the  quadruple  <S, 
which  we  will  call  a continuation  interpretation.  (This  kind  of  dependence 
will  hold  for  all  of  our  target  algebras  describing  direct  or  continuation 
semantics. ) 

Consider  e direct  interpretation  <S,'o^,'K>  and  a continuation  interpretation 
<S,  0,-4>,t3>  with  the  same  S and  7^.  Let  a e H -»•  W be  .the  function  such  that 
a(h)  = Xc.  c*h.  If  then  the  continuation  interpretation  is  said  to 

be  an  image  of  the  direct  interpretation.  If,  in  addition,  0 = S,,  then  it  is 
an  exact  image.  Each  direct  interpretation  obviously  lias  many  Images,  one  of 
which  is  exact.  However,  there  are  continuation  interpretations  (where 
primitive  instructions  have"abnormal"  meanings)  which  are  not  the  image  of  any 
direct  interpretation.  Then: 

Proposition  1 If  the  continuation  interpretation  is  an  image 
of  the  direct  interpretation,  then  is  a homomorphism  from 
FH  to  FW.  If  the  image  is  exact,  then  a left  inverse  for  a 
is  provided  by  the  function  0 e W such  th.at  0(w)  “ w(J  ). 

2-26 


Proof:  The  reader  may  verify  that  a satisfies  the  equations  for  a 
homomorphism  from  FH  to  FW,  and  that  it  is  strict  and  continuous.  In  the 
exact  case,  B(a(h))  = a(h)(Jg)  “ Jg*h  " h.  0 

Thus  we  have  the  following  diagram  of  homomorphisms: 

rinr  1 a (I) 

“rw  FW 

where  a occurs  only  if  the  continuation  interpretation  is  an  image  of  the 
direct  interpretation.  Since  FInF  is  an  initial  algebra,  which  implies 

= ^rW’  diagram  commutes,  i.e.,  all  paths  with  the  same  origin  and 

destination  denote  equal  compositions  of  functions. 

In  other  words,  when  the  continuation  interpretation  is  an  image  of 
the  direct  interpretation,  a maps  the  direct  meaning  of  any  decision  table 
diagram  into  its  continuation  meaning.  Moreover,  when  the  image  is  exact, 

B maps  the  continuation  meaning  back  into  the  direct  meaning. 

Processes 

Let  A be  the  signature  such  that  = {1}  and  A^  = F.  Then  the  domain 
of  process  components  is  InA,  and  the  domain  of  processes  is  Z = T InA. 

Not  only  do  we  want  to  define  the  semantics  of  these  entitles,  but  also  to 
connect  this  semantics  with  the  semantics  of  decision  table  diagrams.  For  this 
purpose,  we  will  nssiuue  that  the  semantics  of  decision  table  diagromr.  is  given 
by  an  arbitrary  target  algebra  FX  (of  which  FH  and  FW  are  instances),  and  we 
will  derive  the  semantics  of  processes  and  their  components  from  FX. 
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Intuitively,  In  a T-algebra,  TX^  means  "Do  nothing,"  rx^(x)  means 


"Execute  £ and  then  execute  x,"  and  rX^(x)  means  "Compute  a table  t of  the 
current  values  of  Boolean  expressions  and  then  exectue  j^(t)."  In  a A-algebra, 

AX  means  "Do  nothing,"  and  AX  (x)  means  "Execute  f,  compute  a table  t of  the 
1 I w- 

current  values  of  Boolean  expressions,  and  then  execute  x(t),"  This  suggests 

VW 

that,  for  any  f-algebra  fX,  we  define  AX  to  be  the  A-£ilgebra  with  the  same 
carrier  such  that 


AXj 


= rx. 


AX.(x)  = rxjrx_(x)) 
r 1 u 


Now  suppose  that  z e Z is  a process.  Then  the  meaning  of  a process 
comionent  z(t)  will  be  y^j^(z(t)).  But  the  meaning  of  z itself  is  "Compute 
a table  t of  the  current  values  of  Boolean  expressions  and  then  execute  the 
meaning  of  z(t),"  or  in  other  words,  fX^j  of  the  function  of  t which  gives  the 
meaning  of  z(t).  Thus  processes  are  mapped  into  their  meanings  by  the  function 


E Z -*■  X such  that 


= ryxt.  = ryp„-z)  . 

The  previously  given  semantic  equations  for  processes  are  simply  assertions 
that  the  direct  and  continuation  semantics  of  processes  are  given  by  6^,^  and 


6 , and  the  direct  and  continuation  semantic  of  process  components  are  given 

rw 


by  and 

The  6-functions  bear  the  following  relationship  to  homomorphisms  between 
r-algebras : 

Proposition  2 If  p e FX  -*•  FX’ , then 

Proof:  Suppose  p c FX  -»■  FX’ . It  is  easily  seen  that  this  implies 
p E AX  -*■  AX'  (which  is  not  surprising,  since  the  definition  of  AX  in  terms 
of  FX  if.  an  instance  of  the  standard  notion  of  a "derived  algebra").  But  then 
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P*y^  c AlnA  AX’  must  be  the  unique  homomorphism  pC^Pj^Cz)) 

" “ *’*i(»‘AX’**>  “ *rx’-  D 

Infonnally,  we  motivated  the  definition  of  processes  by  succestinc  that 
they  were  a kind  of  canonical  form  for  decision  table  diagrams.  If  this  is 
true,  then  it  should  be  possible  to  translate  decision  table  diagrams  into 
processes.  By  regarding  this  translation  as  a kind  of  meaning,  we  can  define 
it  algebraically:  we  will  define  a target  algebra  TZ  such  that  decision  table 
diagrams  are  translated  into  processes  by  the  xuiique  homomorphism  p „ e 
rinr  rz.  it  turns  out  that  the  right  definition  of  fZ  is  the  r-algebra 
with  carrier  Z such  that 

rZj  = At.  AlnAj 
rZj.(z)  = At.  AlnA^(z) 

rz_,(z)  = At.  z(t)(t)  (where  zeT-^Z  = T-^(T-*-  InA)) 
iJ  v,^  • 

This  definition  leads  to  the  following  relationship  between  TZ  and  the 

6-functions : 

Proposition  3 (l)  TZ  is  a key  algebra.  If  it  exists,  the 

unique  homomorphism  from  FZ  to  FX  is  6„„.  (2)  6_^  _ is  a right 

iX  FlnF 

inverse  for  p . 

I U 

Proof:  The  definition  of  FZ  gives  rise  to  the  derived  algebra  FZ. 

By  checking  the  appropriate  homomorphic  equations,  the  reader  may  verify  that 
Ax.  At,  X is  a homomorphism  from  AlnA  to  AZ,  and  is  therefore  equal  to  the 
unique  homomorphism  P.„.  This  implies  that  6 is  the  ii'entity  function  for 
Z,  since  ~ ~ ^ ^ ~ 
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TO  establish  (l),  let  p be  any  homomorphism  from  TZ  to  TX,  Then 
p s=  Proposition  P,  ®PX*  establish  (2),  take  p in 

Proposition  2 to  be  *•  TlnT  TZ.  Then  ^rz*^rinr  ^rz  *°  ^z’  ^ 

Although  rz  is  a key  algebra,  it  is  not  initial,  since  it  is  not 

isomorphic  to  rinr.  In  other  words,  there  are  F-algebras  for  which  there 
is  no  liomomorphism  from  FZ.  However,  we  are  really  only  interested  in  target 
algebras  in  which  D behaves  like  a decision  operation.  This  behavior  is 
characterized  by  the  following  decision  laws,  which  are  the  algebraic 
form\ilation  of  the  equivalences  for  D-operations  given  earlier; 

(1)  (Vx  e X)  FXp(Xt.  x)  = X 

(2)  (Vg  e T (T  X)) 

FXjj(Xt.  FXjj(Xt’.  g(t,t’)))  = rXjj(Xt.  g(t,t)) 

The  following  proposition  shows  that  FZ  is  initial  in  the  restricted 

class  of  F-oIgebras  which  obey  the  decision  laws.  The  reader  may  verify  that 

this  class  includes  FH,  FW,  and  FZ,  but  not  FlnF, 

Proposition  h If  FX  obeys  the  decision  laws,  then  e FZ  FX. 

1 

Proof;  The  necessary  homomorphic  equations  are  established  by; 

*FX^^^I^  ^ FXjj(Xt.  p^j^(AInAj)) 

= p^^(AInAi)  = AXj  = FXp 
«Fx<FZp(z))  = FXjj(p^^»(Xt.  AlnA^(z))) 

= FXjj(Xt.  u^^(AInAp(z)))  = y^j^(AInAp(z) ) = AXp(p^j^*z) 

= FXp(FX^(p^^-z))  = rXp(6p^(z)) 

= FXjj(n^^-(Xt.  ^(t)(t)))  = FXjjCXt.  n^j.U(t)(t))) 

= FXp(xt.  rXjj(xt'.  )i^^{^(t)(t'))))  = rXjj(xt.  rXpjCn^j^-zJt))) 

“ ryxt. 

Strictness  in  established  by: 

= rXj^(p^j^-i)  <=  rXjj(xt.  ''ax^-*-^  " ^ 
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I 

3 


At  this  stage,  we  have  the  following  diagram  of  homomorphisms: 


! 

( 


Composers  and  Monoids 

To  treat  linear  and  general  flow  diagrams,  we  will  derive  A -algebras 
from  the  r~algebras,  and  then  derive  H-algebras  from  the  A-algebras.  However, 
in  the  final  stage,  in  order  to  define  the  semicolon  operation  for  fl-algebras, 
we  will  need  appropriate  composition  functions,  or  composers,  for  each  of  our 
algebras.  We  will  introduce  these  composers  as  we  go  along,  and  show  at  each 
stage  that  the  homomorphisms  we  xise  remain  valid  when  each  algebra  is 
augmented  by  adding  its  composer  as  an  additional  binary  operation. 

In  general,  when  IX  is  a E-algebra  with  carrier  X,  and  E^j  contains  the 
constant  I,  we  write  FnEX  for  the  E-algebra  with  carrier  X -*■  X such  that 

FnEXj  - 

For  o E E , 0 / 1,  nnd  g e S -♦  (X  X), 

FnEX  (g)  « Ax.  EX  (As.  g(H)(x)) 

O o 

When  S={l,  ...  ,n},  the  conventional  form  of  the  last  equation  is: 


i 


i 

J 


J 

1 


FnEX^Cgj^ ’ 

A homomorphism  q e EX  -»■  FnEX  is  said  to  be  a composer  for  EX. 

For  any  signature  E,  we  write  E’  to  Indicate  the  signature  obtained  from  E 
by  adding  ; as  a binary  operator.  When  n is  a composer  for  EX,  we  write  E’X 


to  denote  the  algebra  obtained  from  EX  by  interpreting  ; as  the  binary  operation 
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Z’E  “ n.  (There  is  a potential  ambiguity  here  which  we  will  avoid  by  never 
specifying  more  than  one  composer  for  the  same  algebra.) 

For  example  Fnril  is  the  F-algebra  with  carrier  H -*•  H such  that 
FnrH_  = 

1 n 

FnrH^(g)  = Xh.  rH^(g(h))  = Xh.  g(h)»^(f) 

FnrHjj(g)  = Xh.  rHjj(Xt.  ^(t)(h)) 

= Xh.  Xs.  g(Xb.'B(b,s) , h,  s)  , 

It  is  easily  seen  that  the  function  Xh^.  Xh^.  is  a homomorphism  from 

TH  to  PnfH,  and  is  therefore  a composer  for  TH.  Thus  f’H is  obtained  from  FH 
by  interpreting  the  semicolon  as  F’H_(h  , h„)  = h„*h^ « 

This  construction  has  the  following  general  properties; 

Theorem  2 If  I ^ is  a key  I-algebra  with  a composer 

n,  then  E’X  is  a monoid,  i.e., 

(1)  (Vx  e X)  n{i:Xj,  x)  = X 

(2)  ( Vx  e X)  n(x,  rXj)  = X 

(3)  ( Vx,  y,  z e X)  T)(n(x,  y),  z)  = n(x,  n(y,  z))  . 

If  in  addition,  EX'  is  a E-algebra  with  a composer  and 

p c EX  -*■  EX’,  then  p c E»X  E’X’. 

Proof:  For  a E-algebra  EX  and  x e X,  we  write  EX[x]  to  denote  the 
algebra  obtained  from  EX  by  reinterpreting  I as  the  constant  EXfxJ^  = x. 

It  is  evident  that  p e EX  EX'  Implies  p e J^X'Io(x)].  Also,  the 

definition  of  FnEX  implies  that  Ag.  g(x)  e FnEX  EXix]. 
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Now  suppose  EX  is  a key  algebra  with  the  composer  n e EX  FnEX.  Then: 

(1)  n(EX^,  x)  ■ FnEXj(x)  » x. 

(2)  The  assumption  that  EX  Is  a key  algebra  Implies  that  the  diagram 


^X  ^EX 


FnEX 


Ag.  g(EXj) 

of  homomorphismo  commutes.  Applying  both  compositions  to  x gives  n(x,  EX^) 

(3)  The  following  diagram  also  commutes: 

n Ag.  g(y) 

EX ^FnEX  >«  EX[y] 


= X. 


V 

FnEX 


Ag.  g(n(y)(z)) 


'i/ 

FnEXln(y)] 

Ag.  g(z) 
EXlz]tn(y)(z)] 

= EXln(y)(z)] 


Applying  both  compositions  to  x gives  fi(n(x,  y) , z)  = n(x,  n(y.  z)). 

If  EX'  has  the  composer  n*  and  p e EX  EX',  then  the  following  diagram 
also  commutes: 

n Ag.  g(y) 

EX  9 FnEX  ^ EXty] 


M 


n' 


Ag'.  g'(p(y))  ' P 

EX'  ^ FnEX' > EX' IP (y)] 


4' 


Applying  both  compositions  to  x gives  p(ri(x,  y))  •«  ri'(p  (x)  , p(y)),  which  is  the 

• * 

extra  homomorphic  equation  needed  to  show  p e E*X  -►  E’X'.  D 
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Our  Immediate  goal  Is  to  extend  Diagram  II  to  the  signature  F*.  Suppose 
that  we  can  provide  a composer  for  each  of  the  algebras  In  this  diagram,  and 
that  we  can  show  that  a e F’H  F’W.  Then  since  every  other  homomorphism  in 


(II)  has  the  form  p e FX  FX'  where  FX  is  a key  algebra  (either  FInF  or  FZ), 
Theorem  2 gives  p e F’X  -+■  F’X'.  Thus  (ll)  will  remain  a diagram  of 
homomorphisms  if  we  change  the  signature  of  each  algebra  to  F’,  i,e.,  if  we 
add  the  appropriate  composer  to  each  algebra  as  a binary  operation.  Of  course, 
the  diagram  will  continue  to  commute  since  the  functions  remain  unchanged. 

5y  deriving  the  appropriate  algebras,  verifying  the  resulting  homomorphic 
equations,  and  checking  strictness,  one  can  show  that 

Proposition  ^ (l)  Ah^.  Ah^.  ^2*^1  composer  for  FH. 

(2)  Aw^.  Aw^.  ^ composer  for  FW.  (3)  If  the 

continuation  interpretation  is  an  image  of  the  direct 
interpretation,  then  a e F’H  F’W. 

Moreover,  a composer  for  FInF  is  automatically  provided  by  initiality. 

In  general. 

Proposition  6 For  any  signature  I,  is  the  (unique) 

composer  for  Ilnl. 

To  complete  our  chain  of  reasoning,  we  must  find  a composer  for  FZ. 

To  do  so,  we  use  an  analogue  of  the  idea  of  an  Herbrand  interpretation: 

We  define  a particular  continuation  semantics  in  which  continuations  are 
processes,  and  the  meaning  of  a process  is  a function  which  forms  the 
composition  of  that  process  with  another. 

Let  FW°  be  the  special  case  of  FW  for  the  continuation  interpretation 
in  which  S = T,  0 = InA,^  = Af.  FZ^  and  Ab.  At.  t(b),  so  that  C = Z, 

W = Z Z,  and 
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“ 'z 

rw“(w)  = rZj.-w 

rw°(w)  = Az.  rz.fxt.  w(t,  z))  . 

U U ^ 


Then  FW^  is  identical  with  FnTZ,  so  that 


Proposition  7 ®pyo  (unique)  composer  for  fZ. 

A side  benefit  is  the  right  identity  law  for  the  monoid  f’Z,  6j,yo(z)(rZj)  = z, 
which  implies 

Proposition  8 Xw.  w(rZj.)  e (Z-»^Z)  Z is  a left  inverse 
for  6j,yo* 

Tims  processes  are  canonical  for  continuation  semantics,  since  rw°  is  a 
continuation  semantics  which  alweiys  gives  distinct  meanings  to  distinct  processes. 

In  contrast,  there  is  no  direct  semantics  with  this  property.  For  example, 
the  distinct  processes  1.  and  rZj.(±)  both  mean  J.  in  any  direct  semantics.  Thus 
direct  semantics  induces  a coarser  relation  of  equivalence  for  processes 
(or  other  languages)  than  continuation  semantics.  This  situation  coincides 
witli  the  author's  intuition  about  the  difference  between  direct  and 
continuation  semantics.  It  is  one  of  the  main  reasons  for  not  using  a 
complete-lattice  formalism;  we  have  not  been  able  to  find  a simple 
complete- lattice  formulation  of  direct  semantics  such  that  i.  and  rZ^(l)  have 
the  same  meaning  in  all  direct  and  continuation  semantics. 


Linear  Flow  Diagrams 

Linear  flow  diagrams  are  the  initial  algebra  with  the  signature  A 
such  that  = (I),  = F,  and  A^  B.  Intuitively,  in  a A-algcbra 

I and  each  f have  the  same  meaning  as  in  the  corresponding  P-algebra,  while 


AX^(x^,  X2)  means  "Compute  the  current  value  of  b and  then  execute  Xj^  If  this 
value  is  true  or  X2  If  It  Is  false."  Thus,  for  any  r-algebra  FX,  we  define 
AX  to  be  the  A-algebra  with  the  same  carrier  such  that 

AXj^  = rXj^ 

AXj  = rx^ 

AX^CXi*  X2)  = rX-jj  (At.  condj^(t(b),  Xj^,  X2))  . 


Then: 


Proposition  9 (l)  If  p e FX  FX'  then  p e AX  -*■  AX’ . 

(2)  A composer  for  FX  is  also  a composer  for  AX. 

(3)  If  p e F’X  -*■  F’X’  then  p e A’X  -*■  A’X*. 


The  tedious  but  straightforward  proof  is  left  to  the  reader.  However,  it  should 
be  noted  that  these  results  are  more  than  an  application  of  the  standard  notion 
of  a derived  algebra,  since  they  depend  upon  properties  of  the  conditional 
function  and  the  strictness  of  homomorphisms . 

As  a consequence  (ll)  remains  a diagram  of  homomorphisms  if  we  change 
the  signatiire  of  all  algebras  to  either  A or  A*.  For  A,  we  can  add  the 
initial  algebra  AlnA  and  its  \inique  homomorphisms  to  the  other  algebras: 


(Ill) 


But  Proposition  6 provides  a composer  for  the  added  algebra,  and  Theorem  2 
insures  that  the  added  homomorphisms  extend  to  A’.  Thus  (ill)  remains  a diagram 
of  homomorphisms  if  we  change  each  signature  to  A'. 
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There  Is  no  right  Inverse  for  since  there  are  decision  table 

diagrams  which  cannot  be  mapped  into  any  flow  diagram  with  the  same  meaning 
in  all  semantics.  A simple  example  is  the  decision  table  diagram 

D{>t.  (fj^;  condjj^j.(t(b),  (fgS  I),  (f^;  I)))]  . 

To  execute  this  diagram,  one  must  save  a copy  of  the  initial  state  during  the 
execution  of  f^,  and  then  evaluate  b in  the  saved  state  to  determine  whether 
fg  or  f^  is  to  be  executed  next.  One  cannot  evaluate  b before  executing  f^ 
since  b mjiy  be  nonterminating  and  f^^  may  be  eui  abnormal  instruction. 

A more  spectular  example,  for  which  the  initial  state  must  be  saved 
indefinitely,  is  the  decision  table  diagram  D[^Xt.  0(0,  t)]j,  where  0 e 
Int  (T  Inf)  is  the  least  solution  of 

0(n,  t)  = condj^j,(t(b^) , (f^^;  0(n-H,t)),  (f^;  0(n+l,t))) 

and  {bjj,  b^^,  ...}  is  some  enumeration  of  B. 

The  existence  of  such  decision  table  diagrams  is  regretable,  since  their 
execution  requires  a kind  of  wholesale  state-saving  that  is  not  in  the  spirit 
of  imperative  programming  languages.  It  is  an  open  question  whether  our 
development  could  be  carried  out  with  some  more  restricted  notion  of  decision 
table  diagram  (and  of  process)  such  that  every  decision  table  diagram  in 
equivalent  to  some  flow  diagram. 


General  Flow  diagrams 

General  flow  diagrams  are  the  initial  algebra  with  the  signature  U such 
; that  and  = {;}  O B.  For  any  A ’-algebra  A’X,  we  define 

j fiX  to  be  the  n-algebra  with  the  same  carrier  such  that 


I 

) 
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nXj  - A’Xj 
nX^  - A’Xj(A’Xj) 

nx  = A’x 

• • 

f » 

= . 

Note  that  A’  is  used,  rather  than  A,  to  provide  an  interpretation  of  the  semicolon 

operator  - we  are  finally  letting  our  composers  perform  publicly.  This  is  a 

• • 

standard  instance  of  a derived  algebra,  so  that  p e A’X  -►  A’X'  implies 

p e nx  -*■  nx*. 

Thus,  since  the  functions  in  Diagram  III  are  homomorphisms  of  A ’-algebras, 
they  are  also  homomorphisms  of  n-algebras.  By  adding  the  initial  n-algebra  and 
its  unique  homomorphisms  to  the  other  algebras,  we  obtain: 


Since  ninD  is  initial,  the  diagram  continues  to  commute. 

An  implication  is  that  is  a meaning-preserving  function  from  gcoicral 

to  linear  flow  diagrams,  which  is  slightly  surprising  since,  intuitively, 


general  flow  diagrams  really  seem  to  be  more  general  than  linear  flow  diagrams. 
In  fact  this  is  a valid  intuition,  but  in  a more  subtle  sense:  Call  an  element 
of  an  algebra  equational  if  it  is  the  least  solution  of  a finite  set  of  finite 


uquationH  whose  right  sides  are  constructed  fron  the  operators  of  the  algebra 
(as  in  Section  5.1  of  Reference  2).  Then  there  are  equational  elements  of 
ninO,  such  as  the  least  solution  of 

X - b ((f;  x);  g),  1 

which  are  mapped  by  into  nonequational  elements  of  AlnA.  Essentially, 

the  equational  elements  of  a (1-algebra  can  express  recursion,  while  chose  of 
a A-algebra  can  only  express  Iteration. 

Finally,  we  can  "redefine"  a A-algebra  in  terms  of  an  (1-algebra.  For  any 
(l-algebra  (IX  (actually,  we  will  only  be  Interested  in  (lind  and  (llnA) , let 
AX  be  the  A-algebra  with  the  same  carrier  such  that 

AXj  = (IXj 

AXj(x)  = nx.((ix^,  x) 

- »*b  ■ 

Again  this  is  a standard  Instance  of  a derived  algebra,  so  that  p e (IX  -+■  SIX' 
implies  p e AX  AX'. 

By  applying  this  fact  to  and  adding  the  Initial  A-algebra  and  its 

unique  homomorphism  into  Alnd,  we  get 


AlnA 


'Alnd 


y'  Alnd 


'dInA 


AlnA' 


where  the  algebra  on  the  left  is  the  initial  A-algebra  and  the  algebra  on  the 
right  is  obtained  from  dInA  by  the  above  definition.  But  in  fact  these  two 
algebras  are  the  same,  as  can  be  seen  by  comparing  their  operations.  The  only 
nontrivial  case  occurs  for  the  operator  f,  where 
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AlnA^(x)  = ninA.(ninA^,  x) 

- x) 

■ FnAInAj(FnAInAj) (x) 

* (Xx.  AInAj(FnAInAj(x))) (x) 

- (Xx.  AlnA^(lj^^(x))) (x)  “ AlnAj(x)  . 

Then  since  AlnA  is  initial,  we  have  Uni„A*‘‘AInn  ' ^AlnA  = ^InA’  i-®*’ 
Proposition  10  is  a right  inverse  for 

(But  not  a left  inverse,  since  Wjjjjjyy  is  s many-one  function  from  general  to 
linear  flow  diagrams . ) 


Conclusions 

A variety  of  relationships  among  our  languages  and  their  semantics  are 
specified  by  the  commutativity  of  Diagram  IV,  along  with  Propositions  1,  3.2, 

8,  and  10.  Most  of  this  information  can  be  summarized  as  follows: 

(l)  The  following  are  continuous  functions  among  general  flow  diagrams 
(inR),  linear  flow  diagrams  (inA),  decision  table  diagrams  (Inf),  and  processes 
(Z),  which  preserve  meaning  in  any  direct  or  continuation  semantics: 

^filnA  ^ ^Alnr  ^ 

InR  InA  > Inf  ^ Z 


However,  there  is  no  such  meaning-preserving  function  from  decision  table 
diagrams  to  linear  flow  diagrams. 

(2)  Continuation  semantics  subsumes  direct  semantics  in  the  following 
sense:  For  any  direct  interpretation  there  is  a continuation  interpretation 
(its  exact  image)  and  fiuictions  a e H W and  0 e W -*■  H such  that  a maps  the 


I 

I 


1 


direct  meaning  of  any  general  flow  diagram,  linear  flow  diagram,  decision  table 
diagram,  or  process  into  the  continuation  meaning,  and  3 maps  the  continuation 
meaning  back  into  the  direct  meaning.  Direct  semantics  does  not  subsume 
continuation  semantics  In  a similar  sense. 

(3)  Processes  are  canonical  for  continuation,  but  not  direct  semantics, 
since  there  is  a particular  continuation  interpretation  (used  to  define  rw°) 
which  always  gives  distinct  meanings  to  distinct  processes.  There  is  no  such 
direct  semantics. 
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USER-DEFINED  TYPES  AND  PROCEDURAL  DATA  STRUCTURES 

% AS  COMPLEMENTARY  APPROACHES  TO  DATA  ABSTRACTION 

} 

John  C.  Reynolds 

' Syracuse  University,  Syracuse,  New  York 

ABSTRACT  User-defined  types  (or  modes)  and  procedural  (or  functional) 
data  structures  are  complementary  methods  for  data  abstraction,  each 
providing  a capability  lacked  by  the  other.  With  user-defined  types, 
all  Information  about  the  representation  of  a particular  kind  of  data 
is  centralized  in  a type  definition  and  hidden  from  the  rest  of  the 
program.  With  procedural  data  structures,  each  part  of  the  program 

! which  creates  data  can  specify  its  own  representation,  independently 

* of  any  representations  used  elsewhere  for  the  same  kind  of  data.  However, 

this  decentralization  of  the  description  of  data  is  achieved  at  the  cost 
of  prohibiting  primitive  operations  from  accessing  the  representations 
of  more  than  one  data  item.  The  contrast  between  these  approaches  is 

I 

^ Illustrated  by  a simple  example. 

j 

I 
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Introduction 


User-defined  types  and  procedural  data  structures  have  both  been  proposed 
as  methods  for  data  abstraction,  i.e.,  for  limiting  and  segregating  the  portion 
of  a program  which  depends  upon  the  representation  used  for  some  kind  of  data. 

In  this  paper  we  suggest,  by  means  of  a simple  example,  that  these  methods  are 
complementary,  each  providing  a capability  lacked  by  the  other. 

(1  2) 

The  idea  of  user-defined  types  has  been  developed  by  Morris,  * Llskov 
and  Zilles,^^^  Fischer  and  Fischer, and  Wulf^^^  and  has  its  roots  in  earlier 
work  by  Hoare  and  Dahl. In  this  approach,  each  particular  conceptual  kind 
of  data  is  called  a type,  and  for  each  type  used  in  a program,  the  program  is 
divided  into  two  parts:  a type  definition  and  an  "outer"  or  "abstract"  program. 

The  type  definition  specifies  the  representation  to  be  used  for  the  data  type 
and  a set  of  primitive  operations  (and  perhaps  constants) , each  defined  in  terms 
of  the  representation.  The  choice  of  representation  is  hidden  from  the  outer 
program  by  requiring  all  manipulations  of  the  data  type  in  the  outer  program 
to  be  expressed  in  terms  of  the  primitive  operations.  The  heart  of  the  matter 
is  that  any  consistent  change  in  the  data  representation  can  be  effected  by 
altering  the  type  definition  without  changing  the  outer  program. 

Various  notions  of  procedural  (or  functional)  data  structures  have  been 
developed  by  Reynolds, ^^^Landin, ^^^and  Balzer. In  this  approach,  the  abstract 
form  of  data  is  characterized  by  the  primitive  operations  which  can  be  performed 
upon  it,  and  an  item  of  data  is  simply  a procedure  or  collection  of  procedures 
for  performing  these  operations.  The  essense  of  the  idea  is  seen  most  clearly 
in  its  Implementation:  an  item  of  procedural  data  is  a kind  of  record  called  a 
closure  which  contains  both  an  internal  representation  of  the  data  and  a pointer 
(or  flag  field)  to  code  for  procedures  for  manipulating  this  representation. 

A program  with  access  to  a closure  record  is  only  permitted  to  examine  or  access 
the  internal  representation  by  executing  the  code  Indicated  by  the  pointer,  so  that 
this  code  serves  to  close  off  or  protect  the  internal  representation. 

In  comparison  with  user-defined  types,  procedural  data  scructures  provide 
a decentralized  form  of  data  abstraction.  Each  part  of  the  program  which  creates 
procedural  data  will  specify  its  own  form  of  representation,  independently  of  the 
representations  used  elsewhere  for  the  same  kind  of  data,  and  will  provide  versions 
of  the  primitive  operations  (the  components  of  the  procedural  data  item)  suitable 
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for  this  representation.  There  need  be  no  part  of  the  program,  corresponding 
to  a type  definition,  in  which  all  forms  of  representation  for  the  same  kind 
of  data  are  known.  But  a price  must  be  paid  for  this  decentralization: 
a primitive  operation  can  have  access  to  the  representation  of  only  a single 
data  item,  the  item  of  which  the  operation  is  a component. 

Apparently  this  price  is  inevitable.  If  an  operation  is  to  have  access 
to  the  representation  of  more  than  one  item  of  data,  each  of  which  may  have 
several  possible  representations,  then  its  definition  cannot  be  "decentralized" 
into  one  part  for  each  representation,  since  one  must  provide  for  every  possible 
combination  of  representations.  Presumably  this  requires  the  definition  to  occur 
at  a point  in  the  program  where  all  possible  representations  of  the  operands  are 
known. 


Linguistic  Preliminaries 


Before  illustrating  these  ideas,  we  must  digress  to  explain  (Informally) 

the  language  we  will  use.  It  is  an  applicative  language,  similar  to  pure  LISP^^^^ 

or  the  applicative  subsets  of  GEDANKEN,  PAlJ^^^  or  but  with  a 

(13) 

complete  type  structure  somewhat  like  Algol  68.  Types  will  be  indicated  by 

writing  ex,  where  x is  a type  expression,  after  binding  occurrences  of  identifiers 
(except  where  the  type  is  obvious  from  context) . Type  expressions  are  constructed 
with  the  operators  -»■  denoting  functional  procedures,  x denoting  a Cartesian 
product,  and  + denoting  a named  disjoint  union. 

The  named  disjoint  union  is  sufficiently  novel  to  require  a more  detailed 
explanation.  If  Xj^,  ...  , x^  are  type  expressions  denoting  the  sets  ...  » 
and  ij^,  ...  , 1^^  are  distinct  identifiers,  then 


lit  x^  + 


+ 1 


is  a type  expression  denoting  the  set  of  pairs 


{<ij^,  x>  1 1 £ k ^ n and  x e Sj^}  . 


If  e is  an  expression  of  type  Xj^  with  value  x,  then 

inject  Ij^  e 

is  an  expression  of  type  ij^:  **•  ^n*  ^n  value  ‘^lj^»  x>. 
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Let  e be  an  expression  of  type  Ij^:  + ...  + 1^:  with  value  <i,  x>, 

let  1.  , ...  , i.  be  distinct  members  of  the  set  of  identifiers  {i.,  ...  , i }, 
IC-  X * n 

1 m 

for  1 < j < m let  £.  be  an  expression  of -type  x.  -►  x*  with  value  f.,  and  let 

-3  Kj  j 

e'  be  an  expression  of  type  x*  with  value  x'.  Then 

unloncase  e of  (1,  : t ...  other:  e') 

— ki  1 “ 

is  an  expression  of  type  x*  with  the  value 


1 - i. 


fj^(x) 


1 " i. 


m 


otherwise 


When  m ■ n-,  the  other  clause  will  be  omitted. 

We  use  the  type  expression  nilset  to  denote  a standard  one-element  set, 
whose  unique  member  is  denoted  by  () . 


Integer  Sets  as  a User-Defined  Type 

Our  example  is  an  implementation  of  the  abstract  concept  of  sets  of  integers. 
Using  the  approach  of  user-defined  types,  we  wish  to  define  a type  set  and 
primitive  constants  and  functions 

none  e set 
all  t set 

limit  e integer  x integer  x set  -*■  set 
union  e set  x *set  set 

exists  E Integer  x integer  x set  boolean 


satisfying  the  specifications 


i 


none  ■ {} 

all  ■ The  set  of  all  (machine-representable)  Integers 
limlt(m,  n,  s)  ■>  s n {k  | o £ k £ n} 
union(sl,  s2)  ■ si  u b2 

when  m £ n,  exists  (m,  n,  s)  ■ (ak)  m£k£n  and  k c s 

To  make  our  solution  seem  more  realistic,  we  require  that  the  execution  of  limit 
and  union  should  require  time  and  space  bounded  by  constants  which  are  Independent 
of  their  arguments.  Of  course  this  will  exact  a price  in  the  speed  of  exists. 

An  appropriate  and  simple  solution  is  to  represent  a set  by  a list  structure 
which  records  the  way  in  which  the  set  is  constructed  via  primitive  operations. 
Thus  the  representation  of  a set  is  a disjoint  union,  over  the  four  set-valued 
primitive  functions  (including  constants) , of  sets  of  possible  arguments  for 
these  functions.  More  precisely,  this  representation  is  defined  by  the  recursive 
type  declaration: 

set  ■ nonef:  nilset  + allf:  nilset  + llmltf : integer  x integer  x set 
+ unlonf:  set  x set 

and  the  effect  of  ncme,  allj  limits  or  union  is  to  imbed  its  arguments  -into 
the  appropriate  kind  of  list  element: 

none  •»  Inject  nonef  () 
all  = inject  allf  () 

limit (m,  n,  s)  •=  inject  llmitf  (m,  n,  s) 
unlon(sl,  s2)  •=  inject  unionf  (si,  s2) 

(Roughly  speaking,  we  are  representing  sets  by  a free  algebra  with  constants 
none  and  all,  and  operators  limit  and  union.)  The  entire  computational  burden  of 
interpreting  this  representation  falls  upon  the  function  exists: 
exists (m,  n,  s)  =■  unioncase  s £f 
(nonef:  A().  false, 
allf:  A().  true , 

limltf:  A(ml,  nl,  si).  max(m,ml)  £ min(n,nl) 

and  exists (max(m, ml),  min (n,nl),  s), 
unionf:  X(sl,  s2) . exists(m,  n,  si)  or  exists(m,  n,  s2)  ) 
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(We  assume  Chat  the  operations  and  and  or  do  not  evaluate  their  second  operand 
when  the  first  operand  Is  sufficient  to  determine  their  result.) 

Although  the  above  Is  a definition  of  the  type  eet  which  meets  our 
specifications,  It  can  be  easily  Improved,  even  within  the  time  and  space 
constraints  Imposed  upon  limit  and  union.  For  example,  both  limit  and  union 
can  be  optimized  by  taking  advantage  of  some  obvious  properties  of  sets  - 
the  result  of  limit  can  be  simplified  when  Its  last  argument  Is  none  or  another 
application  of  limits  and  the  result  of  union  can  be  simplified  when  either 
argument  Is  none  or  dll'. 

limit (m,  n,  s)  ■ unloncase  s of 
(nonef:  X().  none, 

llmltf:  X(ml,  nl,  si).  If  max(m,  ml)  jc  mln(n,  nl) 

then  Inject  llmltf  (max(m,ml) , mlnCn.nl),  si)  else  none . 
other;  Inject  llmltf  (m,  n*  s)  ) 
unlon(sl,  s2)  ■ unloncase  si  of 

(nonef:  X().  s2,  allf:  X().  all, 
other;  unloncase  s2  of 

(nonef:  X().  si,  allf:  X().  all, 
other:  Inject  unlonf  (si,  s2)  )) 

In  conclusion,  we  show  how  our  specification  of  Integer  sets  might  be 
"packaged"  In  a language  permitting  user-defined  types: 
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newtype  set  = nonef:  nllset  + allf:  nllset  + liroitf:  integer  x Integer  x set 
+ unlonf:  aet  x set 
with  none  e set  = inject  nonef  (), 
all  t set  = inject  allf  (), 
limit  e integer  x integer  x set  set  ■ 
l(m,  n,  s) .unioncase  s of 
(nonef:  X(),  none, 

limltf:  X(ml,  nl,  si),  if  max  (m,ml)  £ mln(n,nl) 

then  inject  limltf  (max(m,ml},  mln(n,nl),  si)  else  none. 
other;  Inject  limltf  (m,  n,  s)  ), 
union  e set  x set  -*•  set  = 

X(sl,  s2).  unioncase  si  of 
(nonef:  A().  s2,  allf:  X().  all, 
other;  unioncase  s2  of 

(nonef:  X().  si,  allf:  X().  all, 
other;  inject  unionf  (si,  82)  )), 
exists  e integer  x integer  x set  Boolean  «= 

X(m,  n,  s) . unioncase  s of 
(nonef:  X().  false, 
allf:  X().  true. 

liodtf:  X(ml,  nl,  si).  max(m,ml)  min(n,nl) 

and  exists (max (m, ml) , mln(n,nl),  s) , 
unlonf:  X(sl,  s2).  exlsts(m,  n,  si)  or  exists (m,  n,  s2)  ) 
in  <outer  program> 
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The  language  used  here  is  an  outgrowth  of  the  ideas  discussed  in  reference 
14.  A complete  exposition  of  this  language  is  beyond  the  scope  of  this  paper, 
but  the  following  salient  points  should,  be  noted: 

(1)  The  type  declaration  between  newtype  and  with  bin'^’s  all  occurrences  of 
the  type  identifier  set  throughout  the  above  expression  (including  occurrences 
in  <outer  program>).  The  ordinary  declarations  between  with  and  ^ bind  all 
occurrences  of  the  ordinary  identifiers  none,  altj  limit,  unions  and  exists 
throughout  the  expression. 
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(2)  With  regard  to  occurrences  of  eet  between  with  and  the  type 
declaration  behaves  like  a mode  definition  In  Algol  68,  l.e.,  set  Is 
equivalent  to  the  type  expression  on  the  right  side  of  the  type  declaration, 
and  the  type-correctness  of  the  text  In  with  . . . ^ depends  upon  this  type 
expression. 

(3)  In  <outer  program>  occurrences  of  set  behave  like  a primitive  type, 
e.g. , Integer  or  Boolean.  In  other  words,  <buter  program>  must  be  a 
correctly  typed  expression  regardless  of  what  type  expression  might  be 
equivalent  to  set.  This  Insures  that  all  manipulations  of  the  user-defined 
type  In  <outer  program>  must  be  expressed  in  terms  of  the  primitives 
declared  In  with  . . . In. 

(4)  Although  It  Is  not  Illustrated  by  our  example.  It  should  be  possible 
to  declare  simultaneously  several  related  user-defined  types  between 
newtype  and  with.  This  ability  Is  needed  to  permit  the  definition  of 
multiargument  primitive  functions  which  act  upon  more  than  one  user-defined 
type.  An  example  might  be  the  use  of  the  types  point  and  tine  In  a program 
for  performing  geometrical  calculations. 

Integer  Sets  as  Procedural  Data  Structures 

We  now  develop  integer  sets  as  procedural  data  structures.  The  starting  point 
is  the  realization  that  all  we  ever  want  to  do  to  a set  8,  aside  from  using  it  to 
construct  other  sets,  is  to  evaluate  the  Boolean  expression  exists (m,  n,  s). 

This  suggests  that  we  can  simply  equate  the  set  s with  the  Boolean  function 
A(m,  n) . existsim,  n,  s)  which  characterizes  the  only  information  we  want  to 
extract  from  the  set. 

Thus  we  define 

set  = Integer  x Integer  -*■  Boolean 

and  specify  that  if  s e set  represents  the  "mathematical"  set  s^,  then  for  m ±n, 
s(m,  n)  = (ak)  m^k^n  and  k e s^. 

The  need  for  defining  the  primitive  function  exists  has  vanished  since  this 
function  has  been  internalized  - its  value  for  a particular  set  is  simply  the 
(only  component  of  the)  set  itself.  The  remaining  primitive  constants  and 
functions  are  easily  defined  by: 


J 
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none  Xim,  n).  false 
all  “ X(in,  n).  true 
limit (m,  n,  s)  “ X(ml,  nl). 

tnax(m,ml)  £ min(n,nl)  and  B(max(m,ml) , min(n,nl)) 
union(sl,  62)  ••  X(m,  n) . sl(m,  n)  or  82(m,  n) 

In  this  approach,  there  is  no  "outer  prograti"  from  which  the  definition 
set  = integer  x integer  Boolean  is  hidden.  Any  part  of  the  program  can  create 
a set  by  giving  an  appropriate  function  whose  internal  representation  (the 
collection  of  values  of  global  variables  which  form  the  fields  of  the  closure 
record)  can  be  arbitrary.  For  example,  In  augmenting  an  existing  program,  one 
might  write 

X(m,  n).  even(m)  or  (m  < n) 

to  denote  the  set  of  even  integers,  or 

letrec  s « X(m,  n) . (m  £ n)  and  (p(m)  or  s(nri-l,  n))  In  s 

to  denote  the  set  of  integers  satisfying  the  predicate  p.  The  procedural  approach 
insures  that  these  definitions  will  mesh  correctly  with  the  rest  of  the  program, 
even  though  they  introduce  novel  representations. 

This  kind  of  extensional  capability,  which  Is  the  main  advantage  of  the 
procedural  approach,  is  offset  by  two  limitations.  In  the  first  plAce,  although 
(ignoring  computability  considerations)  every  set  can  be  represented  by  a function 
in  integer  x Integer  -*•  Boolean,  the  converse  is  false.  To  represent  a set,  a 
function  s must  satisfy 

n 

s(m,  n)  = s(k,  k) 
k*=m 

for  all  ra  and  n such  that  m ^n.  This  kind  of  condition,  which  cannot  be  checked 
syntactically,  must  be  satisfied  by  all  parts  of  the  program  which  create  sets. 

A more  Important  limitation  is  that  only  the  function  exists,  which  has  been 
internalized  as  (the  only  component  of)  a procedural  data  item,  is  truly  primitive 
in  the  sense  of  having  access  to  the  internal  representation  of  a set.  Essentially, 
we  have  been  forced  to  express  the  functions  limit  and  union  in  terms  of  the 
internalized  exists.  We  are  fortunate  that  our  example  permits  us  to  do  this 
at  all.  Even  so,  we  are  prevented  from  optimizing  limit  and  union  as  we 
did  in  the  user-def ined-type  development.  Tl.are  is  no  practically  effective 
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way  that  n,  s)  can  "see"  whether  a has  the  form  none  or  limit(ml,  nl , el), 

or  that  union(.sl,  b2)  can  "see"  whether  el  or  e2  has  the  form  none  or  all. 

In  fact,  this  difficulty  can  be  surmounted  for  limit  but  not  for  union. 

The  solution  Is  to  Internalize  limit  as  well  as  exiete,  so  that  both  functions 
have  access  to  Internal  representations.  Thus  we  represent  sets  by  pairs  of 
functions: 

set  ■ (Integer  x integer  Boolean)  x (integer  x integer  •+•  set) 

and  specify  that  If  s represents  the  mathematical  set  e^  then  for  m ^n, 

s.l(m,  n)-(3k)m<k<n  and  k e s , 

— — o 

and  for  all  m and  n,  B.2(jn,  n)  represents  the  mathematical  set 
s n {k  I m < k < n} 

(Here  e.l  and  b.2  denote  the  components  of  the  pair  e.) 

In  this  approach,  we  may  define  none  by: 

none  “ (l(m,  n) . false.  X(m,  n).  none) 

Note  the  peculiar  kind  of  recursion  which  Is  characteristic  of  this  style  of 
programming:  the  second  component  of  none  is  a function  which  does  not  call  Itself 
but  rather  returns  itself  as  a component  of  its  result. 

To  define  all  and  union  we  first  define  an  "external"  limit  e integer  x integer 
X eet  eet  which  will  be  called  upon  by  the  Internal  limiting  functions  (i.e., 
the  second  components)  of  all  and  union'. 

limit (m,  n,  s)  ° 

(X(ml,  nl).  max(m,ml)  ^ mln(n,nl)  and  s.l(max(m,ml) , mln(n,nl)), 

X(ml,  nl) . ^ max(m,ml)  min(n,nl)  then 

limit (max (m, ml) , mln(n,nl),  s)  else  none) 

Then 

all  » (X(m,  n).  true,  A(m,  n) . llmlt(m,  n,  all)) 
unlon(sl,  s2)  ° (A(m,  n) . sl.l(m,  n)  £r  s2.1(m,  n) , 

A(m,  n) . llmit(m.  n,  unlon(sl,  s2))  ) 

With  these  definitions,  the  internal  limiting  functions  perform  simplifications 
analogous  to  those  performed  by  limit  in  the  user-def ined-type  approach.  Indeed,  if 
one  examines  the  behavior  of  the  closures  which  would  represent  sets  in  an  implemen- 
tation of  this  definition,  me  finds  that  they  mimic  the  list  structures  of  the  type 
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approach  almost  exactly  (except  for  the  simplifications  performed  by  union). 

I 

But  even  to  someone  who  Is  experienced  with  procedural  data  structures, 
the  internalization  of  limit  is  more  a tour  de  force  than  a specimen  of  clear  j 

programming.  Moreover,  internalization  cannot  be  applied  to  give  a function 
such  as  union  access  to  the  Internal  representation  of  more  than  one  argument, 
l.e.,  we  could  convert  imion{el,  82)  to  a component  of  si  or  of  82  but  not  both. 

Conclusions  i 

In  comparison  with  user-defined  types,  procedural  data  structures  offer  a 
more  decentralized  method  of  data  abstraction  which  precludes  any  Interaction 
between  different  representations  of  the  same  kind  of  data.  This  offers  the 
advantage  of  easier  extensibility  at  the  price  of  prohibiting  primitive  operations 
from  accessing  the  representations  of  more  than  one  data  Item. 

Of  course,  the  two  approaches  can  be  combined.  For  example,  we  can  augment 
our  user-defined-type  definition  to  Include  an  additional  primitive  functset 
c (Integer  x Integer  Boolean)  set  which  accepts  a functional  set  (in  the  sense 
of  the  first  part  of  the  previous  section)  and  produces  an  equivalent  value  of 
type  set.  It  Is  sufficient  to  add  one  more  kind  of  record  to  the  disjoint  union 
defining  set  and  one  more  alternative  to  the  branches  defining  exists: 

newtype  set  = ...  + functsetf:  (Integer  * Integer  •»  Boolean) 

with  . . . 

functset  e (Integer  x Integer  Boolean)  ':*■  set  = Xf . Inject  functsetf  f , 
exists  E Integer  x Integer  x set  ->■  Boolean  = 

X(m,  n,  s) . unloncase  s o^ 

( ...  functsetf:  Xf.  f(m,  n)  ) 

In  <outer  program> 

However,  this  kind  of  combination  Is  hardly  a unification.  To  some  extent, 
the  data-representation  structuring  approach  of  Hoare  and  Dahl^^^  unifies  the 
concepts  of  user-defined  types  and  procedural  data  structures,  but  only  at  the 
expense  of  combining  their  limitations.  It  appears  that  this  is  inevitable; 
that  the  two  concepts  are  Inherently  distinct  and  complementary. 

The  reader  should  be  cautioned  that  this  is  a working  paper  describing 
ongoing  research.  In  particular,  the  linguistic  constructs  we  have  used,  are 
tentative  and  will  require  considerable  study  and  evolution  before  they  can  be 
integrated  into  a complete  programming  language.  The  extension  of  these  constructs 
to  languages  with  imperative  features  is  a particularly  murky  area. 
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TOWARDS  A THEORY  OF  TYPE  STRUCTURE 
John  C.  Reynolds 

Syracuse  University,  Syracuse,  New  York 

INTRODUCTION  The  type  structure  of  programming  languages  has  been  the  subject 
of  an  active  development  characterized  by  continued  controversy  over  basic 
principles. In  this  paper,  we  formalize  a view  of  these  principles  some- 
what similar  to  that  of  J.  H.  Morris. We  Introduce  an  extension  of  the 
typed  lambda  calculus  which  permits  user-defined  types  and  polymorphic  functions, 
and  show  that  the  semantics  of  this  language  satisfies  a representation  theorem 
which  embodies  our  notion  of  a “correct"  type  structure.  We  start  with  the 
belief  that  the  meaning  of  a syntactically  valid  program  in  a "type-correct" 
language  should  never  depend  upon  the  particular  representations  used  to 
implement  Its  primitive  types.  For  example,  suppose  that  S and  S'  are  two  sets 
such  that  the  members  of  S can  be  used  to  "represent"  the  members  of  S'.  We 
can  conceive  of  running  the  same  program  on  two  machines  M and  M’  in  which 
the  same  primitive  type,  say  integer , ranges  over  the  sets  S and  S'  respec- 
tively. Then  if  every  "Integer"  input  to  M represents  the  corresponding 
input  to  M' , and  if  M Interprets  every  primitive  operation  involving  integers 
in  a way  which  represents  the  interpretation  of  M’ , we  expect  that  every 
integer  output  of  M should  represent  the  corresponding  output  of  M' . Of 
course,  this  idea  requires  a precise  definition  of  the  notion  of  "represents"; 
we  will  supply  such  a definition  after  formalizing  our  ill-  strative  language. 

The  essential  thesis  of  Reference  5 is  that  this  property  of  representation 
independence  should  hold  for  user-defined  types  as  well  as  primitive  types. 

The  introduction  of  a user-defined  type  t should  partition  a program  into 
Work  partly  supported  by  AREA  (DAHC04-72-C-0003)  and  NSF  (GJ-41540) . 
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an  "outer"  region  in  which  t behaves  like  a primitive  type  and  is  manipulated  ; 

by  various  primitive  operations  which  are  used  but  not  defined,  and  an  "inner" 
region  in  which  the  representation  of  t is  defined  in  terms  of  other  types,  j 

and  the  primitive  operations  on  t are  defined  in  terms  of  this  representation. 

We  expect  that  the  meaning  of  such  a program  will  remain  unchanged  if  the  inner 
region  is  altered  by  changing  the  representation  of  the  type  and  redefining  its 
primitive  operations  in  a consistent  manner. 

We  also  wish  to  consider  the  old  but  neglected  problem  of  polymorphic 
functions,  originally  posed  by  Strachey.  Consider  the  construction  of  a 
program. in  which  several  different  types  of  arrays  must  be  sorted.  We  can 
conceive  of  a "polymorphic  sort  function"  which,  for  any  type  t,  accepts  an 
array  with  elements  of  type  t and  a binary  ordering  predicate  whose  arguments 
must  be  of  type  t,  and  produces  an  array  with  elements  of  type  t.  We  would 
like  to  define  such  a function,  and  to  have  each  call  of  the  function 
syntactically  checked  to  Insure  that  it  is  type-correct  for  some  t.  But  in  a 
typed  language  a separate  sort  function  must  be  defined  for  each 

type,  while  in  a typeless  language  syntactic  checking  is  lost.  We  suggest  that 
a solution  to  this  problem  is  to  permit  types  themselves  to  be  passed  as  a 
special  kind  of  parameter,  whose  usage  is  restricted  in  a way  which  permits 
the  syntactic  checking  of  type  correctness. 

An  Illustrative  Language 

To  illustrate  these  ideas,  we  introduce  an  extension  of  the  typed  lambda 

' (8) 

calculus  which  permits  the  binding  of  type  variables.  Although  this  language 
is  hardly  an  adequate  vehicle  for  programming,  it  seems  to  pose  the  essense  of 
the  type  structure  problem,  and  it  is  simple  enough  to  permit  a brief  but 
rigorous  exposition  of  its  semantics. 

We  begin  with  a typed  lambda  calculus  in  which  the  type  of  every  expression 
can  be  deduced  from  the  type  of  its  free  variables.  For  this  purpose  it  is 
sufficient  to  supply,  at  each  point  of  variable  binding,  a type  expression 
describing  the  variable  being  bound.  For  example. 

Ax  c t.  X 

denotes  the  identity  function  for  objects  of  type  t,  and 
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Af  e t t.  Ax  e ti  f(f(x)) 

denotes  the  doubling  functional  for  functions  over  t. 

It  Is  evident  that  the  meaning  of  such  expressions  depends  upon  both 
their  free  normal  variables  and  their  free  type  variables  (e.g.,  t In  the  above 
examples) . This  suggests  the  addition  of  a facility  for  binding  type  variables 
to  create  functions  from  types  to  values,  called  polymorphic  functions.  For 
example. 

At.  Ax  e t.  X 

Is  the  polymorphic  Identity  function,  which  maps  t Into  the  Identity  function 
for  objects  of  type  t,  and 

At.  Af  e t -»■  t.  Ax  e t.  f(f(x)) 

Is  the  polymorphic  doubling  functional,  which  maps  t Into  the  doubling  functional 
for  functions  over  t. 

The  next  step  is  to  permit  the  application  of  polymorphic  functions  to  type 
expressions,  and  to  Introduce  a new  form  of  beta-reduction  for  such  applications. 
In  general.  If  r Is  a normal  expression  and  w Is  a type  expression,  then 

(At.  r)[w] 

denotes  the  application  of  the  polymorphic  function  At.  r to  the  type  w,  and 
is  reducible  to  the  expression  obtained  from  r by  replacing  every  free  occurrence 
of  t by  w (after  possible  alpha-conversion  to  avoid  collision  of  variables) . 

For  example,  the  application  of  the  polymorphic  Identity  function  to  the  type 
integer  real. 

(At.  Ax  c t.  x)  [Integer  -*•  real] 

reduces  to  the  identity  functional  for  functions  from  integer  to  real, 

Ax  E Integer  real,  x . 

Finally,  we  must  Introduce  a new  kind  of  type  expre  sion  to  describe  the 
types  of  polymorphic  functions.  We  write  At.  w to  denote  the  type  of  polymorphic 
function  which,  when  applied  to  the  type  t,  produces  a value  of  type  w.  Thus 
if  the  expression  r has  the  type  w,  then  the  expression  At.  r has  the  type  At.  w. 
For  example,  the  type  of  the  polymorphic  identity  function  Is  At.  t t,  while 
the  type  of  the  polymorphic  doubling  functional  Is  At.  (t  -»■  t)  (t  ->  t) . 
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In  providing  polymorphic  functions,  we  also  provide  user-defined  types. 

For  example,  suppose  outer  Is  an  expression  In  which  cmp  Is  a primitive  type 
(l.e.,  a free  type  variable)  Intended  to  denote  complex  numbers,  add  and  magn 
are  primitive  functions  (l.e.,  free  normal  variables)  Intended  to  denote 
addition  and  magnitude  functions  for  complex  numbers,  and  1 Is  a primitive 
constant  (l.e.,  a free  normal  variable)  Intended  to  denote  the  square  root  of  -1. 
Suppose  we  wish  to  represent  complex  numbers  by  pairs  of  reals,  and  to  represent 
addition,  magnitude,  and  the  square  root  of  -1  by  the  expressions 

addrep  c (real  x real)  x (real  x real)  (real  x real) 
magnrep  c (real  x real)  -*■  real 
Irep  c (real  x real) 

This  representation  can  be  specified  by  the  expression 

(Acmp.  Xadd  c cmp  x cmp  -*■  cmp.  Xmagn  c cmp  real.  XI  c cmp.  outer) 

t [real  x real]  (addrep)  (magnrep)  (irep)  . 

(Our  illustrative  language  docs  nut  Include  the  Cartesian  product,  but  its 
^ addition  should  not  pose  any  significant  problems.)  Admittedly,  this  is  hard 

I 

[ to  read,  but  the  problem  should  be  amenable  to  judicious  syntactic  sugaring. 

We  now  proceed  to  develop  a formal  definition  of  our  illustrative 
language,  culminating  in  a "representation  theorem"  which  asserts  its  type 
correctness. 

Notational  Preliminaries 

For  sets  S and  S',  we  write  S x s'  to  denote  the  Cartesian  product  of  S and 

^ S',  S =^S'  or  S'^  to  denote  the  set  of  functions  from  S to  S',  and  when  S and  S' 

are  domains  (In  the  sense  of  Scott)  S S'  to  denote  the  set  of  continuous 

functions  from  S to  S'.  If  F is  a function  which  maps  each  member  of  S into 

a set,  we  write  n F(x)  to  denote  the  set  of  functions  f such  that  the  domain 
xeS 

of  f is  S and,  for  each  x e S,  f(x)  c F(x) . 

I For  f e S ■=^S',  x e S,  x'  e S',  we  write  [f|x|x']  to  denote  the  function 

Xy  E S . ^ y = X then  x ' else  f ( y) . 


! 
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Syntax 

To  formalize  the  syntax  of  our  language,  we  begin  with  two  disjoint, 
countably  Infinite  sets:  the  set  T of  type  variables  and  the  set  V of  normal 
variables.  Then  U,  the  set  of  type  expressions. Is  the  minimal  set  satisfying: 

(la)  If  t c T then: 

t c W. 

(lb)  If  Wj^,  W2  c W then: 

(Wi  W2)  E W. 

(lc)  If  t c T and  w e W then: 

(dt.  w)  e U. 

(To  keep  the  syntax  simple,  we  have  specified  complete  parentheslzatlon,  but 
in  writing  particular  type  expressions  we  will  omit  parentheses  according  to 
common  usage.) 

From  the  fact  that  &t.  w Is  supposed  to  bind  the  occurrences  of  t In  w, 
one  can  define  the  notions  of  free  and  bound  occurrences  of  type  variables, 
and  of  alpha-conversion  of  type  expressions  In  an  obvious  manner.  We  write 
w w'  to  indicate  that  w and  w'  are  alpha-convertible.  (In  a more  complex 
language,  the  relation  might  be  larger;  the  Idea  Is  that  it  must  be  a 
decidable  equivalence  relation  which  Implies  that  w-  and  w*  have  the  same 
meaning. ) 

One  can  also  define  the  notion  of  substitution  In  an  obvious  manner. 

,Vj 

We  write  Wj^  to  denote  the  type  expression  obtained  from  Wj^  by  replacing  every 
free  occurrence  of  t by  W2,  after  alpha-converlng  Wj^  so  that  no  type  variable 
occurs  both  bound  In  w^  and  free  In  W2. 

To  define  normal  expressions,  we  must  capture  the  Idea  that  every  normal 
expression  has  an  explicit  type.  Specifically,  an  assignment  of  a type 
expression  to  every  normal  variable  whl^h  occurs  free  In  a normal  expression  r 
must  Induce  an  assignment  of  a type  expression  to  r Itself  which  Is  unique 
(to  within  alpha-conversion).  For  all  Q e V ^W  and  w e W we  write  to 
denote  the  set  of  normal  expressions  for  which  the  assignment  of  Q(x)  to  each 
normal  variable  x will  Induce  the  assignment  of  w to  the  normal  expression  Itself. 
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Then  R_  Is  the  minimal  family  of  sets  satisfying: 
Qw 


(2a)  If  Q c V W and  x e V then: 


X e R. 


QQ(x) 


(2b)  If  Q e V^W,  w^.  w^.  W2  e W,  = w',  e and  t R^^. 


, then : 


<'l  '2>  ‘ V, 


(2c)  If  Q c V =^W,  w^,  e W,  X e V,  and  r e R[q|x|wj^]  Wj 


then: 


(Xx  e w^.  r)  e 


(2d)  If  Q e V =^W,  e W,  t e T,  and  r e Rq^^^.Wj^) 


then: 


(rlw,])  e R „ 


(2e)  If  Q e V =^W,  weW,  teT.re  Rq^t  and  t does  not  occur  free 


in  Q(x)  for  any  x which  occurs  free  in  r,  then: 


(At.  r)  e R- 


Q(At.w) 

(Again  we  have  specified  complete  parentheslzatlon,  but  will  omit  parentheses 
according  to  common  usage.)  By  structural  induction  on  r,  it  is  easy  to  show 


that  r E R-  and  r e R„  , implies  w = w' . 
CJw 


The  restriction  on  t in  (2e)  reflects  the  fact  that  the  meaning  of  t in 
At.  r is  distinct  from  its  meaning  in  the  surrounding  context.  For  example, 
Q(x)  “ t does  not  imply  At.x  e Rq^^j. 


Semantics 


We  will  interpret  our  language  in  terms  of  the  lattice-theoretic  approach 
of  D.  Scott^^  ^^intuitively  the  effect  of  a type  expression  is  to  produce  a 
Scott  domain  given  an  assignment  of  a domain  to  each  free  type  variable  occurring 
in  the  type  expression.  Thus  we  expect  the  meaning  of  type  expressions  to  be 
given  by  a function 

B E W=^l!)^fi:J»'t> 

where  13  denotes  the  class  of  all  domains. 

To  specify  B we  consider  each  of  the  cases  in  the  syntactic  definition  of  W: 

(la)  Obviously, 

B[t](D)  = D(t) 

(We  will  use  barred  variables  to  denote  functions  of  T,  and  square 
brackets  to  denote  application  to  syntactic  arguments.) 

(lb)  We  intend  w^^  ->  W2  to  denote  the  domain  of  continuous  functions 
from  the  domain  denoted  by  Wj^  to  the  domain  denoted  by  w^.  Thus 

B[Wj^  -»■  W2](D)  = arrow(BfWj^]  (D)  , B[w2](D)) 

where  arrow  £(*()>«  "t))  ==?  "0  satisfies 
arrow(Dj^,  D2)  = -+■  D2. 

(lc)  We  intend  At.  w to  denote  a set  of  functions  over  the  class  of 
domains  which,  when  applied  to  a domain  D will  produce  some  element 
of  the  domain  denoted  by  w under  the  assignment  of  D to  t.  Thus 

BtAt.  w]  (D)  = delta(AD  e "t?.  Bfw][D|t|D]) 

where  delta  t ('t)^^*!!?)  ■=?  t)  satisfies 

delta (0)  S n 0(D) 

De-b 

We  leave  open  the  possibility  that  delta (0)  mav  be  a proper  subset 
of  the  above  expression.  (Indeed,  if  we  are  going  to  avoid  the 
paradoxes  of  set  theory  and  consider  delta(6)  to  be  a domain,  it  had 
better  be  a very  proper  subset.) 

By  structural  induction,  one  can  show  that  w = w'  implies  B[w]  = B[w'],  and 

that 

Blw^  I t I BlW2](D)] 
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The  effect  of  a normal  expression  is  to  produce  a value,  given  an 
assignment  of  domains  to  its  free  type  variables  and  an  assignment  of  values 
to  its  free  normal  variables. (We  will  call  the  latter  assignment  an  environment . ) 
However,  this  effect  must  conform  to  the  type  structure.  When  given  a type 


assignment  D,  a normal  expression  r e must  only  accept  environments  which 


map  each  variable  x into  a member  of  the  domain  B[Q(x)](D),  and  r must  produce 
a member  of  the  domain  B[w](D).  Thus  we  expect  that,  for  all  Q e V W and 


w e W,  the  meaning  of  the  normal  expressions  in  will  be  given  by  a function 


where 


Env_(D)  = n B[Q(x)](D)  . 


xeV 


To  specify  the  we  consider  each  of  the  cases  in  the  syntactic 


definition  of  R . Essentially  the  specification  is  an  immediate  consequence 


of  the  intuitive  meaning  of  the  language,  guided  by  the  necessity  of  making  the 
functionalities  come  out  right: 


(2a)  ^QQ(x) 


(2b)  r2](D)(e)  = [r^]  (D)  (e)  Ir2]  (D)  (e)  ) 


(2d)  M 


(2e)  MQ(^t..w)^^‘'‘  Mj^[r][DltlD](e) 


Xae  B 

[r[w„]  ] (D)  (e)  = (M, 


Q(At.wpf^nD)(e))(B[w2](D)) 


1 
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Representations 

Before  we  can  formulate  the  representation  theorem,  we  must  specify  what 
we  mean  by  representation. 

For  D,  D'  e i),  the  set  of  representations  between  D and  D' , written 
rep(D,  D'),  is  the  set  of  continuous  function  pairs 


rep(D,  D')  { «t>,  (|)>  \ (|i  e D ->  D' , e D'  -*■  D,  3 1^,  E 1^,  } 


where  denotes  the  identity  function  on  D.  For  x c D,  x*  e D' , and 


p = <((>,  ij)>  e rep(D,  D'),  we  write 

p:  X *->■  X* 


and  say  that  x represents  x'  according  to  p if  and  only  if 

X C t/)(x' ) 

or  equivalently. 


♦(x)  E x'  . 


A pragmatic  justification  of  this  rather  ad  hoc  definition  is  that  it  will 
ultimately  make  the  representation  theorem  correct.  (Although  this  would  still 
be  true  if  we  took  rep(D,  D')  to  be  the  set  of  projection  pairs  between  D and  D', 
l.e.,  if  we  replaced  the  requirement  -Ip  by,  = 1^  .)  However,  some 
intuition  is  provided  by  the  following  connection  with  the  notion  of  representation 
between  sets.  Conventionally,  we  might  say  that  a representation  between  a set  S 
and  a set  S'  is  simply  a function  n e S '=^S',  and  that  x e S represents  x'  e S' 


according  to  ir  iff  ttCx)  = x'  . But  if  we  take  D and  D'  to  be  the  powerset  domains 


s s * 

2 and  2 (with  £ asE),  and  ((>  and  ijj  to  be  the  pointwise  extensions  of  tt  and 


its  converse  (as  a relation),  then  p = <<t>,<l>>  is  a representation  between  D and  D', 
and  p:  s s'  iff  every  x e s conventionally  represents  some  x'  e s'  according 
to  ir. 


The  following  is  an  obvious  and  useful  extension  of  our  definition. 


For  D,  D'  E "b  , we  define 


rep(D,  D') 


n rep(D(t),  D'(t))  . 
teT 
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The  Representation  Theorem 

At  this  point,  we  can  formulate  a preliminary  version  of  the  representation 
theorem.  Consider  the  set  of  normal  expressions  R_  ,and  suppose  that  D,  D'  e f)"' 
and  p e rep(D,  D'),  so  that  for  each  type  variable  t,  p(t)  is  a representation 
between  the  domains  D(t)  and  D'(t).  Moreover,  suppose  that  e and  e'  are 
environments  such  that, for  each  normalvarlable  x,  e(x)  represents  e'(x) 
according  to  the  relevant  representation,  l.e.,  p(Q(x)).  Then  we  expect  that 
the  value  of  any  r e when  evaluated  with  respect  to  D and  e should 
represent  the  value  of  the  same  normal  expression  when  evaluated  with  respect  to 
D'  and  e',  according  to  the  relevant  representation,  l.e.,  p(w). 

More  formally: 

Let  Q e V =^W,  w e W,  D,  D'  elD,  p e rep(D,  D'),  e e Ehv^  (D) , 


and  e'  e Env^  (D’).  If 


X e V)  p(Q(x)):  e(x)  n-  e' (x) 


(Vr  e p(w):  M^^[r](D)(e)  m-  M^[r]  (O' ) (e' ) 

However,  this  formulation  has  a serious  flaw.  In  choosing  p,  we  assign 
a representation  to  every  type  variable,  but  not  to  every  type  expression, 
so  that  the  representations  p(Q(x))  and  p(w)  are  not,  fully  defined.  Moreover, 
we  can  hardly  expect  to  assign  an  arbitary  representation  to  every  type  expression. 
For  example,  once  we  have  chosen  a representation  for  Integer  and  a representation 
for  real,  we  would  expect  that  this  choice  would  determine  a representation  for 
integer  -►  real  and  for  any  other  type  expression  constructed  from  integer  and  real. 

In  brief,  we  have  underestimated  the  meaning  of  type  expressions.  Not  only 
must  B[w]  map  an  assignment  of  domains  to  type  variables  into  a domain,  but  it  must 
also  map  an  assignment  of  representations  into  a representation.  If  we  can  extend 
the  meaning  of  B to  do  so,  then  a correct  formulation  of  the  representation 
theorem  is: 

Let  Q e V W,  w e W,  D,  D'  gT),  p e rep(D,  D'),  e e Env^  (D) , 
and  e'  e Env^  (D').  If 

(Vx  G V)  B[Q(x)](p):  e(x)  K e'(x) 


(Vr  E B[w](p):  MQ^[r  ] (D)  (e)  Mjj^,[r]  (D' ) (e* ) 
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The  Full  Semantics  of  Type  Expressions 


In  order  to  extend  the  semantic  function  B,  we  first  note  that  the 
combination  of  domains  and  representations  forms  a category.  We  write  C to 
denote  the  category,  called  the  category  of  types.  In  which  the  set  of  objects 
Is  "t)  , the  set  of  morphlsms  from  D to  D’  Is  rep(D,  D'),  composition  Is  given  by 

» '1'^  “ 

and  the  Identity  for  D Is 

V • 

From  the  category  of  types,  we  can  form  two  further  categories  by  standard 

(13)  X 

constructions  of  category  theory,  we  write  C to  denote  the  category  In  which 
the  set  of  objects  Is  t)  , the  set  of  morphlsms  from  D to  D'  Is  rep(D,  D'), 
composition  Is  given  by 

(p'*p)(t)  = p'(t)*p(t) 

and  the  Identity  for  D Is  given  by 

°^D(t)  • 

We  write  Funct(C,  C)  to  denote  the  category  in  which  the  objects  are  the 

functors  from  C to  C and  the  morphisms  from  0 to  0 ' are  the  natural  transformations 

from  0 to  0',  i.e.,  the  functions  n e 11  rep (0(D) ,0* (D))  such  that,  for  all 

Del) 

D,  D'  e “j[)  and  p e rep(D,  D’), 

0'(p)*n(D)  = ti(D')*0(p) 

Composition  is  given  by 

(n'Ti)(D)  = n'(D)*Ti(D) 
and  the  identity  for  0 is  given  by 
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We  have  seen  that  the  meaning  B[w]  of  a type  expression  w must  map  the 

T T 

objects  of  C into  the  objects  of  C and  the  morphlsms  of  C into  the  morphlsms 

of  C.  Moreover,  if  our  formulation  of  the  representation  theorem  Is  to  be 

meaningful,  we  must  have 

p e rep(D,  D')  implies  B[w](p)  e rep(B[w](D),  Btw](D')) 

Thus,  at  least  if  we  can  satisfy  the  appropriate  laws,  we  expect  to  extend 

T T 

B[w]  from  a function  f rom  D to D Into  a functor  from  C to  C. 

Indeed,  by  pursuing  the  analogy  of  categories  with  sets  and  functors 
with  functions,  we  can  Induce  the  main  structure  of  the  definition  of  B[w]. 

For  each  of  the  cases  In  the  syntactic  definition  of  W: 

(la)  Blt](D)oD(t) 

B[t](p)  = p(t) 

(lb)  B[wj^  •>  W2](D)  = arrow(B[Wj^](D),  B[w2](D)) 

B[wj^  W2](p)  = arrow(B[Wj^](p),  B[w2)(p)) 
where  arrow  Is  a blfunctor  from  C x C Into  C. 

(lc)  B[At.  w]  “ delta  • abstract 

T 

where  abstract  Is  the  functor  from  C In.to  Junct(C,  C)  such  that 

abs tract (D) (D)  = B[w][D|t|D] 

abstract(D)(p)  = B[w]t#-|t|p] 

abstract(p)(D)  = B[w]  [p  1 1 

and  delta  Is  a functor  from  Funct(C,  C)  Into  C. 

Even  before  defining  the  functors  arrow  and  delta.  It  can  be  shown  that 

T 

B maps  every  type  expression  into  a functor  from  C into  C,  that  w *=  w'  Implies 
B[w]  = B[w'l»  and  that 

BtWj^|”2](D)  = B[Wj^][  D I t ( B[w^](D)  ] 

BtWi|”2](p)  = B[Wj^][  p I t I Btw2](p)  ] 


4-12 


The  Functors  arrow  and  delta 


The  definition  of  the  functor  arrow  is  fairly  obvious.  Essentially, 
its  action  on  representations  is  to  produce  the  only  reasonable  composition 
which  matches  domains  correctly;  For  all  e 10 , 

arrow(Dj^,  D^)  = -+■  D2  . 

For  all  e rep(D^,  D|)  and  <(|(2,  il>2>  e repCD^,  Dp, 

arrow(<((.j^,\l)j^>,  <412. = 


(The  action  of  arrow  on  representations  is  similar  to  the  method  used  by 
Scott  to  construct  retraction  or  projection  pairs  for  function  spaces.) 


The  definition  of  arrow  and  the  properties  of  representations  give 


the  following  lemma: 

Let  f e -*■  D2,  f e -<■  e rep(Dj^,  D|) , and  p2  e repCD^,  Dp. 

Then 

arrow(pj^,  p^)  : f »-»•  f ' 

if  and  only  if,  for  all  x e D^^  and  x'  e Dp 

Pj^:  X x’  implies  *"*■  f'(x')  . 

which,  with  the  definition  of  B^gives  the  following  lemma: 

Let  Wj^,  £ U,  p c rep(D,  D'),  f e B[w^  -*  W2](D),  and  f e B[w^  -»■  W2)(D'). 
Then 

B[wj^  -*■  W2]  (p)  : f <-►  f ' 

if  and  only  if,  for  all  x e B[Wj^](D)  and  x'  e B[Wj^](D'), 

X x’  implies  Blw2](p):  f(x)'-»-  f’(x’) 


(As  an  aside,  we  note  that  the  definition  of  arrow  establishes  a connection 
between  our  notion  of  representation  and  the  concept  of  simulation^^^^ypically , 
one  says  that  a function  tt  e S =^S'  is  a simulation  of  a relation  r S'  s x S by  a 
relation  v' S S'  x S'  iff  iT*r  Sr'^ir  (where  • denotes  relational  composition). 


But  if  f,  f,  4>,  and  tp  are  the  pointwise  extensions  of  r,  r' , n,  and  the  converse 
of  n,  then  iT*r  E r'*Tr  iff  arrow(p,  p):  f »-*•  f,  where  p = <41,  4)>.) 


The  definition  of  the  functor  delta  is  less  obvious.  For  all  functors 
0 from  C to  C,  delta(0)  is  the  complete  lattice  with  elements 

{ f I f e n 0(D)  and  (Vd,  D'  Et»(Vp  e rep(D,D'))  0(p) : f(D)  H-  f(D')  } 

Det) 

with  the  partial  ordering  f £ g iff  (\/d  e D)  f(D)  g(D)  • For  all  natural 

transformations  n from  0 to  0', 

delta(n)  = 

< Xf  e delta(0).  XD  e t).  [n(D)  ] j^(f  (D) ) , 

Xf  e delta(0').  XD  zV-  ln(D)]2(f (D))  > 

At  this  point,  we  must  admit  a serious  lacuna  in  our  chain  of  argument. 

Although  delta(0)  is  a complete  lattice  (with  (13f)(D)  = {f(D)  | f e F } ), 

it  is  not  known  to  be  a domain,  l.e.,  the  question  of  whether  it  is  continuous 

and  countably  based  has  not  been  resolved.  Nevertheless  there  is  reasonable 

hope  of  evading  the  set-theoretic  paradoxes.  Even  though  n 0(D)  is  immense 

Deti 

(since  “iD  is  a class),  the  stringent  restrictions  on  membership  in  delta(0) 
seem  to  make  its  size  tractable.  For  example,  if  f e delta(0) , then  the  value 
of  f(D)  determines  its  value  for  any  domain  isomorphic  to  D. 

The  definition  of  delta  and  the  properties  of  representations  give 
the  lemma: 

Let  n be  a natural  transformation  from  0 to  0',  f e delta(0)  and 
f e delta(0').  Then 

delta (n) : f f ' 

if  and  only  if,  for  all  D,  D'  el),  and  p e rep(D,  D'), 

n(D’)-0(p):  f(D)  f’(D')  . 

which,  with  the  definition  of  B,  gives: 

Let  t e T,  w e W,  p e rep(D,  D'),  f e B[At.  w](D),  and  f e B[&t.  wKD'). 
Then 

B[At.  w]  (p)  : f f * 

if  and  only  if,  for  all  D,  D'e  "D,  and  p e rep(D,  D'), 

B[w][p|t|p]:  f(D)  <-»-  f'(D’)  . 

From  the  final  lemmas  obtained  about  arrow  and  delta,  the  representation 
theorem  can  be  proved  by  structural  induction  on  i. 
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Some  Syntactic  Manipulations 

We  have  explored  our  Illustrative  language  semantically  rather  than 
syntactically,  l.e.,  we  have  provided  it  with  a mathematical  meaning  Instead 
of  investigating  the  syntactic  consequences  of  reducibility . However,  an 
obvious  question  is  raised  by  the  fact  that  every  expression  in  the  typed 
lambda  calculus,  but  not  the  untyped  lambda  calculus,  has  a normal  form. 

We  have  been  unable  to  resolve  this  question  for  our  language. 
Nevertheless,  the  language  permits  some  interesting  constructions  which  are 
not  possible  in  the  typed  lambda  calculus. 

For  example,  consider  the  following  normal  expressions: 

p H At.  Xf  e t t.  Ax  e t.  f(  ...  f(x)  ...  ) 

n «-  ^ 

, . / X / X “ times 

of  type  Ti  = At.  (t  t)  (t  ->■  t) , 

0 = Ah  e n.  At.  Af  e t t.  Ax  e t.  f(h[t]  f x) 

of  type  IT  ->■  :r  (We  assume  application  is  left-associative.), 

o H Ag  e n -*•  IT.  Ah  e IT.  g(h[n]  g p^^) 

of  type  (tt  •+■  tt)  -»•  (ir  x),  and 


3 

H Aw 

e IT. 

w 

[tt  -» 

■ tt]  ( 

■+ 

(tt 

tt)  . 

Then 

the  : 

e 

Pn+1 

3 

^itri-1 

“ o 

(3 

p_) 

ni 

3 

Pq  Pn  “ P 

n+1 

3 

Pm+1 

PQ  " 

3 

Pm 

Pi 

3 

Pmfl 

Pn+1 

s; 

3 P 

n, 

m 

From  the  last  three  equations  it  follows  that  3 p p ~ p,/  x>  where  ijj(n,m) 

m n ifitn,ra; 

is  Ackermann's  function. 


; i 

i 

f A 
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Further  Remarks 


Since  the  writing  of  the  preliminary  version  of  this  paper,  considerable 
attention  has  been  given  to  the  "serious  lacuna"  mentioned  above.  We  have 
managed  to  show  that  delta(6)  is  a continuous  lattice,  but  not  that  it  is 
countably  based.  Conceivably,  our  notion  of  representation  is  too  restrictive, 
which  would  tend  to  make  delta (0)  unnecessarily  large. 
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An  Introduction  to  Transaction  Processing  Systems 
Daniel  K.  Wood  and  Robert  G.  Sargent 


ABSTRACT 

An  Introduction  to  Transaction  Processing  Systems  Is  given.  Their 
characteristics,  hardware  and  software  requirements,  a design  methodology, 
their  current  development  and  areas  needing  future  research  are  briefly 
described. 
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I.  INTRODUCTION 

The  use  of  computers  in  processing  numeric  and  non-numeric  data  has 
advanced  significantly  since  their  introduction.  This  has  resulted  in  most 
organizations  becoming  dependent  upon  their  use.  Computerized  systems 
have  been  developed  for  all  kinds  of  applications,  have  increased  in 
sophistication,  and  have  reduced  the  manhours  required  to  perform  numerous 
kinds  of  operations.  Several  different  kinds  of  computer  systems  have 
been  developed  such  as  batch,  on-line,  time-sharing,  and  minis.  With 
the  rapid  technology  changes  taking  place  in  computer  systems  today,  one 
cannot  anticipate  the  kind  of  computer  systems  that  will  result  in  the 
future  nor  the  various  uses  they  will  be  put  to. 

Computerized  systems  have  had  a major  effect  on  how  many  organi- 
zations operate.  These  systems  usually  process  and  handle  operational 
data  and  information  entirely  different  than  V7as  used  previously  and 
provide  information  that  was  previously  unattainable.  One  type  of  compu- 
terized system  causing  operating  changes  are  Transaction  Processing  Systems 
(TPS) . These  systems  are  rapidly  being  developed  and  implemented  in  a 
wide  variety  of  applications.  Most  TPS  are  on-line  interactive  systems 
that  process  business  transactions  immediately.  Examples  of  such  systems 
are  airline  and  hotel  reservation  systems,  bank  credit  systems,  and 
certain  inventory-ordering  systems.  This  paper  provides  an  introduction 
to  transaction  processing  systems  and  discusses  some  areas  needing 
research. 


II.  CHARACTERISTICS  OF  TRANSACTION  PROCESSING  SYSTEMS 


Transaction  Processing  Systems  (TPS)  generally  have  certain  common 
characteristics.  They  are  the  following  [2]; 

(a)  The  Input  data,  called  transactions,  are  of  pre-deflned 
types . 

(b)  The  data  entry  Is  through  terminals  and  the  operating 
procedure  Is  usually  quite  simple  to  allow  "non-experts" 
to  use  such  systems. 

(c)  The  programs  to  process  the  transactions  are  prepared  and 
stored  In  the  computer  in  advance  and  are  "invisible"  to 
the  user. 

(d)  The  response  time  is  fast  providing  the  user  with  the 
desired  information  and/or  verifying  the  input  immediately. 

(e)  The  system  maintains  an  integrated  data  base.  The  processing 
of  transactions  usually  involves  updating,  retrieving, 
manipulating,  or  entering  new  data  in  the  data  base. 

Simply  stated,  most  TPS  are  a specialized  type  of  on-line  system 
that  allow  non-experts  to  use  them  interactively  for  processing  pre- 
defined transactions  using  previously  written  stored  programs  to  inter- 
act with  a data  base. 

III.  PROCESSING  OF  TRANSACTIONS 

After  transactions  (data)  are  generated  in  the  organization's 
operation,  they  are  entered  into  the  computer  through  a terminal  that  is 
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either  hardwired  or  connected  by  a telephone  line.  A front-end  pro- 
cessor Is  usually  linked  between  the  terminal  and  the  computer.  This 
processor  typically  screens  the  transaction  for  legitimacy,  forwards 
them  to  the  computer,  coordinates  the  arrival  and  departure  of  trans- 
actions, and  may  provide  editing  capability  of  Incoming  data.  After  the 
transactions  pass  through  the  front  end  processor  to  the  computer,  they 
are  assigned  priorities  based  upon  their  transaction  type  and  urgency  of 
the  processed  results.  These  transactions  are  then  queued  for  service 
by  the  CPU.  When  the  CPU  becomes  available,  the  computer  makes  avail- 
able the  necessary  application  programs  to  process  the  first  transaction 
and  then  executes  these  programs. 

The  executing  of  transaction  processing  application  programs  generally 
involve  some  interaction  with  the  computer  managed  data  base.  The 
simplest  interaction  is  just  to  retrieve  some  Information  stored  in  the 
data  base.  Complicated  interactions  may  include  several  updates  (inser- 
tion, alternation  or  deletion)  of  the  records  in  different  files. 

Numerical  calculation  may  be  an  integral  part  of  the  processing  of 
transaction  data.  Usually,  the  logic  is  straightforward,  even  though  it 
may  not  be  trivial.  The  time  required  for  processing  different  types 
of  transactions  will  be  the  total  time  needed  in  loading  the  application 
programs,  accessing  and  storing  data  from  the  data  base  files,  and 
numerical/non-numerical  manipulation  of  data.  This  will  generally  take 
much  less  time  than  one  second.  Since  this  time  is  rf'latively  small, 
the  technique  of  sv;apping  programs  in  and  out  of  main  storage  during 


5-5 


IV.  TRANSACTION  PROCESSING  CONTROL  SYSTEM 

A software  system  is  needed  to  perform  and  control  the  tasks  neces- 
sary for  a TPS.  These  software  systems  (programs)  are  called  such  names 
as  transaction  (processing)  control  system,  transaction  processing 
(operating)  executive,  teleprocessing  monitor,  and  transaction  (processing) 
monitor.  The  tasks  of  concern  are  generally  the  following  [8] : 

— Terminal  management  - Host  and  effectively  control  the  data 

transfer  between  a telecommunication  network  of  hetero- 
geneous mix  of  terminals  and  the  application  programs. 

— Multitask  control  - Schedule  and  support  the.  concurrent  pro- 
cessing of  a number  of  application  programs  for  the  wide 


i 


data  base  files.  Support  the  scheduling  and  Initiation 
of  all  file  Item  requests  made  by  the  application  programs. 


1 


— Storage  management  - Allocate  and  control  of  storage  for  programs, 
storage  for  Input/output  buffering  areas  and  temporary 
storage  of  data. 

— Program  management  - Provide  a multiprogramming  capability  while 
offering  a real-time  program  fetch  capability.  Intercept 
program  Interrupts  to  prevent  total  system  termination. 

— Error  handling  - Detect  and  handle  error  conditions  caused  by 

hardware  or  software.  Provide  dump  facility  to  assist  in 
analysis  of  programs  and  transaction  undergoing  development 
or  modification. 

In  satisfying  these  tasks  the  following  services  are  generally 
provided  for; 

1.  Edit  the  Input  transaction  data. 

2.  Check  transaction  input  for  validity. 

3.  Journalize  transaction  inputs  for  use  as  backup  trail. 

4.  Analyze  transaction  inputs  and  establish  the  linkage  of 
data  to  proper  application  programs. 

5.  Schedule  and  control  the  processing  of  application  programs 
as  required  by  the  transaction  type. 

6.  Control  of  the  data  transfer  between  application  programs 
and  terminals. 

7.  Handle  exception  conditions. 


i 
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8.  Manage  the  data  transfer  to  and  from  the  data  base  files 


as  required  by  the  application  programs. 

9.  Manage  the  application  programs  in  the  memory  store. 

10.  Generate  reports  as  required  by  the  application. 

11.  Generate  intermediate  transaction  data  for  later  processing. 

12.  Manage  the  transient  data  generated  during  execution  of 
application  programs. 

13.  Monitor  the  creation  of  application  programs. 

These  software  systems  usually  run  under  the  operating  system  in 
a multiprogrammed  environment  as  a single  privileged  job.  There  are, 
however,  applications  where  the  whole  computer  system  is  designed  and 
operated  as  a dedicated  TPS.  In  these  applications,  the  transaction 
processing  control  system  is  merged  into  the  operating  system  of  the 
computer  system. 

V.  HARDWARE  AND  SOFTWARE  REQUIREMENTS 

Figure  1 is  a pictorial  representation  of  a general  purpose  trans- 
action processing  system.  To  have  such  a TPS,  certain  hardware  and 
software  are  necessary.  Since  each  TPS  can  be  separately  designed, 
there  may  be  some  differences  between  the  software  and  hardware  of 
each. 

The  following  equipment  (hardware)  are  generally  requl  ed: 

— Front  end  processor.  A front  end  processor  (communication 

front  end)  is  necessary  to  Interface  the  lines  connecting 
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remote  terminals  to  the  central  processing  unit.  It 
performs  such  functions  as  assembling  Incoming  messages, 
detecting  transmission  errors,  and  routing  responses  back 
to  the  terminal  operators.  In  large  systems,  the  front- 
end  may  be  a minicomputer  and  may  have  associated  with  It 
magnetic  tapes  or  disks  for  message  queueing.  In  smaller 
systems,  front-end  functions  may  be  integral  to  the 
central  processing  rather  than  assigned  to  a separate 
processor. 

-Central  processing  unit.  This  is  used  to  process  all  the  trans- 
actions. As  on-line  processing  systems  are  more  vulner- 
able to  system  malfunction,  dual  processing  units  are 
usually  configured  In  the  system  for  greater  reliability. 

-Main  memory  modules  and  secondary  direct  access  storage.  For 
storage  of  data  base  files  that  must  be  immediately 
accessible,  direct  access  storage  is  needed  to  support 
on-line  processing.  These  storages  may  range  from  fixed- 
head  drums  or  disks  to  large-capacity  disk  files. 

-Terminals.  Terminals  are  necessary  equipment  for  input  and 
output.  In  systems  where  terminals  are  used  for  one 
dedicated  application,  special  purpose  terminals  may  be 
desirable.  Such  terminals  may  be  equipped  with  special- 
purpose  function  keys,  specialized  printing  symbols,  and 
templates  or  masks  for  specialized  displays.  Printing 
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outputs  on  predesigned  forms  can  be  done  directly  through 

! 

the  terminal  as  a result  of  processing  the  transaction 

application  programs.  These  terminals  further  reduce  the  j 

j 

works  of  the  terminal  operators  and  eliminate  possibilities  | 

1 

of  typing  errors,  hence  the  rate  of  processing  transaction  j 

may  be  Increased.  For  systems  that  support  many  diversified  | 

applications  and  handling  of  relatively  unrestricted  j 

retrieval  requests  are  expected,  general  purpose  terminals 

may  be  more  desirable.  A standard  low-speed  Teletype 

device  or  an  input  keyboard  combined  with  a data  display 

screen  will  suffice  for  input  transaction  data  as  well  as 

receiving  processed  output.  When  the  applications  are 

complex,  minicomputers  and  microprocessors  are  quite 

often  used  as  "intelligent  terminals."  They  are  equipped 

with  enough  storage  capacity  and  logic  so  that  extensive 

£ 

preliminary  processing  can  be  performed  before  transmitting 
a transaction  to  the  central  processing  unit. 

The  software  support  needed  includes: 

— The  operating  system.  Operating  system  is  needed  to  control 

other  software  packages  designed  for  various  services.  It 
maintains  overall  control  of  system  operations  by  scheduling 
the  execution  of  all  other  programs,  allocating  main  memory, 
establishing  job  priorities,  servicing  interrupts,  communi- 
cating with  the  computer  operator,  and  performing  similar 
housekeeping  tasks. 
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•Transaction  Processing  Control  System.  This  software  system 


performs  and  controls  the  tasks  necessary  to  operate  the 
TPS  as  described  above.  It  may  Include  the  front  end  control 
system  and  the  data  base  management  system  listed  below. 

■Front  end  control  system.  This  software  system  is  required  to 
control  the  operation  of  the  multiple  remote  terminals. 
Besides  controlling  the  terminals  and  communication  lines, 
and  interrupting  the  operating  system  when  action  must  be 
taken  on  incoming  messages,  it  may  also  perform  such  func- 
tions as  input  message  error  handling,  input  editing,  output 
report  and  display  formatting.  Features  such  as  provisions 
of  security  and  data  logging  capability  as  well  as  other 
supports  to  facilitate  recovery  may  also  be  obtained  in  this 
software  system. 

-Data  base  management  system.  The  data  base  management  system 

services  the  application  programs  and  the  system  users  by 
providing  retrieval  and  updating  capability  for  the  file 
records  of  an  on-line  system.  It  is  designed  to  efficiently 
handle  file  and  data  access  methods  for  manipulating  the 
records  in  data  base.  Other  functional  supports  may  include 
maintaining  the  integrity  of  data  and  protect  the  data  base 
against  unauthorized  access  or  modification. 
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VI.  DESIGNING  TRANSACTION  PROCESSING  SYSTEMS 


Prior  to  designing  and  developing  an  actual  transaction  processing 
system,  the  following  analysis  should  be  conducted  to  provide  informa- 
tion about  the  characteristics  of  the  transactions,  the  data  base  files, 
and  the  processing  functions. 

1.  Review  the  nature  of  transactions,  including  frequency  and 
information  content  of  each  type  of  transaction. 

2.  Establish  the  required  content  of  output. 

3.  Define  output  requirements. 

4.  Identify  the  input  information  needed  to  produce  the  required 
output. 

5.  Determine  the  source  of  data  input  needed  to  produce  the 
output. 

6.  Determine  the  method  of  data  entry. 

7.  Determine  the  data  base  size,  information  content  and  accessing 

activities. 

8.  Determine  the  conditions  when  information  should  be  processed. 

9.  Determine  the  processing  algorithms. 

Given  a specific  application,  the  following  is  an  outline  of  stages 
in  the  process  of  designing  transaction  processing  systems  [3].  This 
process  is  iterative  and  a decision  at  any  stage  can  have  a significant 
effect  on  the  final  design.  On  the  other  hand,  it  is  also  affected  by 
the  previous  taken  decisions. 


1.  Select  logical  record  contents  - select  the  items  making  up 
the  record  and  determine  the  key  for  identifying  the  record. 

2.  Rationalize  logical  records  - examine  logical  records  to 
determine  the  possiblity  of  combining  or  altering  record 
contents  in  order  to  simplify  the  data  structure. 

3.  Select  record  format  - determine  the  length  of  records  and 
decide  whether  the  record  should  be  of  fixed  or  variable 
length. 

4.  Select  file  organization  - choose  the  file  organization 
methods  among  indexed  sequential,  multi-list  randomized 
addressing  or  directing. 

5.  Consideration  of  logical  protection  of  master  files  to  assure 
the  continued  accuracy  and  completeness  of  data  files  as 
well  as  to  guarantee  that  the  information  held  in  the  files 
will  not  be  disclosed  to  unauthorized  users. 

6.  Processing  mode  of  master  file  consideration  - determine 
whether  random  processing  (processing  in  the  order  of  in- 
coming transactions)  or  reorder  the  transactions  according 
to  the  records  in  logical  sequence  is  more  advantageous. 

7.  Dialogue  design  - select  among  the  following  alternatives 
in  man-machine  dialogue: 

a)  dialogue  using  mnemonics. 

b)  computer-- initiated  dialogue  ("menu-selecting") . 

c)  form- filling. 


d)  mixture  of  computer- initiated  and  operator-initiated 


dialogue  ("hybrid  dialogue"). 

8.  Communication  network  design  - examine  the  peak  volume 
of  transactions  to  be  handled  in  different  locations  and 
determine  the  number  of  terminals  needed  in  each  location. 

9.  Establish  hardware  and  software  environment  - establish  the 
mechanism  of  task  operations  (transaction  processing  control 
system) — i.e.,  its  method  of  dispatching  tasks,  allocating 
storage,  loading  of  programs,  etc. 

10.  Software  design  - design  of  application  programs  and  utility 
programs . 

11.  Storage  device  consideration  - Decide  which  physical  medium 
should  contain  the  program  modules,  the  files  and  the 
dialoque  message. 

12.  Select  proper  block  size  for  buffering  - select  primary 
storage  block  size  for  message  buffers,  file  buffers,  and 
relocatable  or  overlayable  areas. 

13.  Decide  the  number  of  each  type  of  buffer. 

14.  Establish  storage  requirements. 


15.  Develop  model  of  system  - to  allow  the  study  of  the  effects 
of  various  volumes  and  proportions  of  messages  on  the 
response  time  and  throughput  capabilities. 


VII.  CURRENT  DEVELOPMENT  OF  TRANSACTION  PROCESSING  SYSTEMS 


There  are  a number  of  transaction  systems  In  operation  today  and 
the  rate  of  applications  are  rapidly  Increasing.  Many  larger  firms  have 
TPS  available  as  well  as  several  smaller  firms.  Some  of  the  better 
known  TPS  available  for  general  use  are  TIP  from  Univac,  CICS  from  IBM  [8], 
TPE  from  Honeywell  [7],  TASK/MASTER  from  Turnkey  Systems,  INTERCOMM  from 
Informatics,  ENVIRON/1  from  Clncom  Systems,  and  SHADOW  II  from  Culllnane 
Corporation. 

As  previously  mentioned,  applications  are  found  In  a vast  variety 
of  organizations  from  banking  to  government.  The  earliest  TPS  was  the 
SABRE  system  developed  for  American  Airlines  for  passenger  flight 
inventory. 

In  the  literature  there  are  few  detail  documentations  of  TPS.  Some 
military  organizations  use  the  TPE  of  the  Honeywell  system  [5,14].  One 
large  TPS  described  [4]  is  used  by  Time,  Inc.  that  has  200  CRT  terminals, 
a data  base  of  five  billion  characters,  processes  750,000  transactions 
per  week,  and  provides  a mean  response  time  of  one  second. 

VIII.  PERFORMANCE  EVALUATION  OF  TRANSACTION  PROCESSING  SYSTEMS 

To  date,  there  are  essentially  no  documented  studies  on  performance 
evaluation  of  TPS.  Performance  evaluation  are  commonJ.y  used  in  computer 
systems  for  design,  selection,  and  tuning  (peaking).  A common  and 


desired  approach  to  use  is  the  modeling  approach.  There  are  essentially 
no  models  for  TPS  in  the  literature.  TPS  are  similar  to  time-sharing 


system,  but  are  different  enough  that  these  models  are  usually  not 
applicable.  This  is  a major  area  of  TPS  needing  research. 

IX.  FUTURE  RESEARCH  NEEDS 

As  stated  above,  a major  void  exists  in  a lack  of  models  and  per- 
formance evaluation  of  TPS.  This  is  not  surprising  in  that  other  types 
of  computer  systems,  e.g.  batch  and  time-sharing,  were  developed  and 
became  operational  before  models  of  their  behavior  were  developed  for 
performance  evaluation.  For  TPS,  this  is  the  next  major  step  needed  in 
their  development. 

Prior  to  development  of  models  of  TPS  for  design,  selection,  and 
tuning,  an  understanding  of  their  operation  is  necessary.  This  means 
empirical  studies  must  be  made  of  operating  TPS  to  obtain  the  necessary 
insights,  data  on  their  stochastic  behavior,  and  their  resource  require- 
ments. Certain  behavior  can  be  hypothesis,  but  must  be  determined  if 
true.  For  example,  are  service  requests  approximately  constant  for  each 
type  of  transaction?  Are  transaction  arrivals  Poisson?  Are  resource 
requirements  similar  for  various  types  of  transactions? 

After  some  empirical  studies  have  been  performed,  models  for  TPS 
can  be  developed.  One  just  has  to  look  at  the  large  number  of  models 
developed  of  time-sharing  systems  to  become  aware  of  the  fact  that  a 
large  amount  of  research  and  development  is  necessary  for  model  de- 
velopment of  TPS. 
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X.  SUMMARY 


Transaction  Processing  Systems  were  described  and  pointed  out  to  be 
a new  type  of  computer  system  that  Is  rapidly  being  developed  and  Imple- 
mented. It  was  also  noted  that  there  are  essentially  no  reported  models 
or  studies  on  performance  evaluation  of  TPS  and  this  Is  the  next  step 
needed  In  their  development. 


I 

) 
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Abstract — An  associative  processor  organization  with  application  to  weather  j 

computations,  and  specifically,  to  a two-level  atmospheric  general  circulation  model  | I 

developed  by  Mlntz  and  Arakawa  Is  used  as  the  application  problem  to  be  Implemented  i | 

for  system  analysis  and  design.  These  system  parameter  changes  Include  the  arlthme-  j i 

tlc-loglc  capabilities,  the  number  of  processing  elements,  different  speeds,  1 j 

structures,  and  access  techniques  of  the  memory,  addition  of  a high  speed  temporary 
storage,  and  the  use  of  an  auxiliary  storage  unit.  Pertinent  data  are  calculated 
for  all  these  systems  and  a cost-effective  system  is  finally  determined  after  the 
comparisons  of  these  analysis  results  are  made.  This  final  system  Is  then  evaluated 
and  compared  with  the  original  system. 

I . INTRODUCTION 

Since  It  would  be  Impossible  for  a system  designer  to  expect  a computer 
system  to  be  cost-effective  for  all  areas  of  applications.  In  this  study  an  associa- 
tive processor  organization  is  selected  to  solve  the  weather  computation  problems. 

This  Is  because  associative  processing  provides  a natural  combination  of  arithmetic- 
logic  and  search-retrieval  capabilities  which  is  a desired  characteristic  for  many 
mathematical  problems,  such  as  matrix  operations,  fast  Fourier  transform,  and  par- 
tial differential  equation  [1].  The  solution  of  partial  differential  equations  is 
essentially  the  basic  mathematical  tool  for  weather  computations.  Among  many  other 
weather  problems,  a two-level  atmospheric  general  circulation  model  developed  by 
Mlntz  and  Arakawa  [2]  Is  chosen  as  one  representative  exair  le  for  demonstrating  the 
suitability  of  the  ass  dative  parallel  processor  for  such  problems.  The  essential  I 

use  of  this  general  circulation  model  is  as  an  experimental  tool  for  studying  the 
nonlinear  behavior  of  the  atmosphere.  It  Is  Intended  to  use  this  model  to  explore  I 

the  sensitivity  and  response  of  the  world's  climate  to  either  deliberate  or  Inad-  1 

vertent  modification,  through  the  various  settings  of  the  initial  and  boundary 
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II.  AN  ASSOCIATIVE  PROCESSOR  ORGANIZATION 

In  order  to  make  our  investigation  meaningful  an  associative  processor  organi- 
zation is  first  assumed.  The  system  consists  mainly  of  five  component  [3]  as  shown 
in  Figure  1.  It  is  assumed  that  there  are  a total  of  1024  PE's  in  this  system.  Each 
PE  has  a 256-blt  associative  word  divided  into  four  32-bit  fields  (A,  B,  C,  D) , 16 
bits  of  temporary  storage  (TS) , an  M bit,  and  one  bit-serial  arithmetic-logic  unit. 
All  1024  M bits  form  a mask  register  which  is  used  to  activate  or  deactivate  the 
corresponding  PE's.  Data  words  stored  in  the  fields  are  fetched  bls*-sequentlally  to 
be  processed  by  the  arithmetic-logic  unit.  The  results  are  stored  back  to  the 
designated  destination. 


1 


1 

i : 

! 1 


Figure  1.  An  associative  parallel  processor  organization. 

The  data  words  are  32-bit  long  and  represented  in  two's  complement  form  * 

throughout  the  system.  Floating-point  numbers  have  an  8-bit  exponent  and  a * 

24-blt  mantissa. 

i 

III.  IMPLEMENTATION  OF  THE  GENERAL  CIRCULATION  MODEL  ON  AP 

i 

The  original  program  of  the  Mintz-Arakawa  two-level  atmospheric  general 
circulation  model  was  written  in  FORTRAN  [2].  It  has  been  translated  into  parallel 

processing  programs  [4].  The  whole  program  is  constructed  mainly  of  two  components.  ' 

t 

All  ith  bits  of  a given  set  of  operands  from  the  1th  bit  slice,  or  bis,  of  the  set. 


i 
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The  first  is  the  updating  of  variables  in  five  time-steps  by  computing  their  time 
derivatives  without  the  influence  of  the  source  terms.  During  each  time-step  the 
computing  procedure  is  processed  twice  as  required  by  the  backward  differencing 
scheme.  We  shall  designate  this  computing  procedure  as  PART  I program  which  is 
executed  in  a total  of  ten  times  during  the  five  time-steps.  After  the  variables 
have  been  updated  ten  times  through  the  five  time-steps  by  PART  I program,  the  ef- 
fect of  the  source  terms  is  added  to  the  computation  of  the  time  derivatives.  The 
part  of  program  which  produces  the  source  terms  is  designated  as  PART  II  program. 

PART  I and  PART  II  programs  are  segmented  into  18  and  17  subprograms,  re- 
spectively. These  subprograms  are  executed  one  at  a time  in  a sequential  manner 
with  each  program.  All  these  subprograms  are  used  to  update  the  basic  variables  of 
the  general  circulation  model  [2].  Each  variable  has  a data  set  of  the  size  of 
46  72  ■■  3312.  Since  the  capacity  of  the  AP  is  assumed  to  be  1024,  each  of  these 

data  sets  as  well  as  other  generated  along  the  process,  will  have  to  be  segmented 
into  groups  of  proper  size.  For  implementation  details  and  other  considerations 
see  Reference  [4]. 

IV.  OPERATIONAL  CHARACTERISTICS  AND  ANALYSIS  OF  THE  GENERAL 
CIRCULATION  MODEL 

A.  Operation  Counts 

Based  upon  the  parallel  processing  programs  we  first  obtain  the  operation 
counts  of  each  subprogram.  The  distribution  of  operations  is  then  analyzed. 

Table  1 gives  the  operation  counts  for  OVERALL  program  which  includes  the 
execution  of  PART  I program  ten  times  and  the  execution  of  PART  II  program  once 
over  the  complete  data  sets. 

B.  Operation  Distributions 

From  Table  1 we  can  see  that  arithmetic  operations  take  up  more  than  one 
third  of  all  operations;  data  transfers  among  PE's  take  up  more  than  one  fifth; 
while  load  and  store  operations  arc  about  ISZ  and  5%,  respectively. 

Another  type  of  operation  distribution  is  obtained  by  calculating  the  dis- 
tribution according  to  the  system  components  involved  in  the  operations.  Two  major 
categories  of  operations  are  operations  Involving  both  the  backup  storage  and  PE's 
and  operations  involving  PE's  alone  (Table  2).  Within  each  of  these  two  categories 
of  operations  some  operations  require  data  manipulating  f motions  and  others  do  not* 
The  total  Involvement  of  the  data  manipulator  is  also  given  in  Table  2. 

C.  Estimation  of  Execution  Time 

The  most  fundamental  operation  executed  in  PE's  to  perform  various  arithmetic 
operations  is  the  addition  of  two  bises.  This  addition  consists  of  the  reading  of 
two  bises  to  be  added,  execution  of  the  addition  and  the  writing  of  tht  resultant 
conditions. 


Table  1.  Operation  Counts  and  Execution  Times  of  Overall  Program 


Total  Execution 


Number  of  Execution  Time  Time  for  OVERALL 
Operations  per^Oper^tion  Program (ysec) 




Ft  ' 

1528 

126.7 

193903.2 

Common 

X 

1544 

107.2 

165516.8 

ARITHMETIC 

+ 

8660 

136.3 

1180358. 

Field 

X 

4354 

207.4 

903019.6 

/ 

1496 

269.9 

403770.4 

X,/  by  2^ 

1616 

2.4 

3878.4 

1 

3888 

20.8 

80870.4 

2 

696 

49.75 

34626 

LOAD 

Pattern 

3 

1516 

49.75 

75421 

1 

1880 

49.75 

93530 

One-Bls 

292 

0.65 

189.8 

1 

1066 

27.225 

29021.85 

STORE 

Pattern 

2 

292 

59.775 

17454.3 

h 

904 

50.95 

-4- 

1 

1 

46058.8 

1 4 

440 

59.775 

26301 

1 

One-Bis 

1 

28 

0.85 

23.8 

. Direct 

884 

8.0 

7072 

; TRANSFER 

Shift 

1 

1 

4424 

16.1 

71226.4 

j 

1 

M 

2522 

16.1 

40604.2 

j One-Bls 

3504 

0.25 

876 

j TEMPORARY  STORAGE 

1423 

27.2 

38705.6 

LOGIC 

650 

0.05 

32.5 

SET  MASK 

5054 

0.10 

252.7 

MULTIPLICATE 

660 

28.9 

1 

170.4 

MULTIPLE  WRITE 

1136 

0.15 

n 

1 

2547.2 

SEARCH 

398 

6.4 

1 

2878.2 

24 

468 

6.15 

670.8 

BIT  SHIFT 

8 

312 

2.15 

374.4 

FIXED-POINT  ADD 

C 

156 

2.4 

374.4 

F 

156 

2.4 

3438802.15 

TOTAL 

j 51947 

|No.  of  Operatlot|s/sec  * 15106 

6-4 


sum  bis  into  PE's.  With  the  semiconductor  type  of  PE  associative  memory  (PEAM) , 
two  blses  can  be  read  out  simultaneously,  one  In  true  form  and  the  other  In 
complement  form.  Thus  a single  bis  addition  takes  300  nsec,  with  the  following 
timing  assumptions  for  our  system. 


Operation: 

Read 

PE 

Write 

PE 

Execute 

Read  backup 
storage 

Write  backup 
storage 

Set  DM 
control 

DM 

delay 

Tlme(n.8ec) : 

100 

150 

50 

500 

750 

100 

250 

Based  on  the  above  assumptions,  the  execution  times  for  various  operations 
and  routines  can  be  estimated.  And  according  to  the  estimated  execution  time  of  the 
various  basic  operations  we  can  calculate  the  total  execution  time  for  the  OVERALL 
program.  These  are  also  given  In  Table  1.  Notice  that  more  than  80Z  of  the  total 
execution  time  is  spent  on  arithmetic  operations.  A discussion  on  how  to  improve 
the  total  performance  by  speeding  up  the  arithmetic  operations  will  be  given  in  the 
following  section. 

The  execution  time  distribution  of  this  system  (System  1)  according  to  system 
components  can  also  be  found  in  Table  2.  Table  2 shows  that  only  13.413!  of  the 
total  execution  time  is  spent  on  executing  operations  involving  both  the  PE's  and 
the  backup  storage,  the  rest  of  the  time  is  on  operations  executed  in  PE's  alone. 

The  operations  which  involve  the  data  manipulator  take  up  about  11.5%  of  the  total 
execution  time  in  processing  the  general  circulation  model. 

D.  Utilization  and  Efficiency  of  PE's 

We  define  utilization,  u,  and  efficiency,  E,  of  PE's  as  follows: 

No.  of  PE's  utilized  in  operation  i . , 

*^1  Total  No.  of  PE's  available  ^ ^ 

E = I u.  • t./T  = I (2) 

i i 

where  t^  is  the  execution  time  of  the  operation  i,  T is  the  total  execution  time  of 
a program  and  r^  the  percentage  of  t^  with  respect  to  T. 

From  the  parallel  processing  programs  we  see  that  almost  all  the  arithmetic 
operations  involve  all  the  PE's  where  data  are  stored.  This,  however,  does  not  give 
a 100%  utilization.  This  is  because  the  subprograms  are  executed  four  times  for 
four  groups  of  data  of  each  complete  data  set  and  the  first  three  groups  of  data 
occupy  all  the  14  « 72  •=  1008  PE's  but  the  fourth  group  utilizes  only  4 x 72  = 288 
PE's.  Thus  an  average  utilization  for  arithmetic  operations  is  calculated  as 
follows:  -1  1 

u^  = X (1008  + 1008  + 1008  + 288)  x 
- 0.8086 
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Table  2*  Operation  Counts  and  Execution  Times  According 
to  System  Components  for  OVERAIX  Program 


Execution 

uperacion 

(System  10) 

Count 

% 

Time  (us) 

% 

Time  (us) 

% 

Backup  Storage 

With  DM 

5547 

10.68% 

283470.85 

8.24% 

51985.30 

4.38% 

♦ PE's 

Without 

DM 

7536 

14.51% 

177887.45 

5.17% 

42980.15 

3.62% 

TOTAL 

13083 

25,19% 

561358.30 

13.41% 

94965.45 

8,00% 

With  DM 

6946 

13.37% 

111830.60 

3.25% 

111830.60 

9.42% 

PE's  Alone 

Without 

DM 

31918 

61.44% 

2865899.00 

83.34% 

980005.50 

82.58% 

TOTAL 

38864 

74.81% 

2977729.60 

86.59% 

1091836.10 

92.00% 

Total  DM 
Involvement 

12493 

24.05% 

495301.45 

11.49% 

163815.90 

13.80% 

The  load  and  store  operations  have  four  different  patterns  and  each  pattern 
involves  the  loading  or  storing  of  different  subsets  of  groups  of  data  set.  When 
different  numbers  of  PE's  are  being  loaded  or  stored  in  various  patterns  of  opera- 
tions, different  average  utilizations  result.  Utilizations  for  transfer  operations 
can  similarly  be  calculated.  Table  3 includes  all  the  utilizations  for  different 
operations. 

Now  that  we  have  obtained  the  PE  utilizations  of  the  major  operations  we  can 
calculate  the  PE  efficiencies  for  processing  PART  I,  PART  II  and  OVERALL  programs 
according  to  Eq,  (2).  Table  3 also  gives  the  efficiencies  of  the  three  programs. 

E.  Relative  Performance  Measure 

Evidently,  the  overall  performance  of  the  processor  for  the  general  circula- 
tion model  programs  cannot  rely  on  Che  efficiency  alone.  At  least  two  other  im- 
portant items  should  also  be  included  in  the  consideration,  these  are  Che  total 
execution  time  and  the  cost  of  the  hardware.  But  for  the  moment,  we  shall  concen- 
trate only  on  the  performance  aspect  of  the  system. 

We  now  define  the  performance  measure  of  a given  system  to  be 


where  E is  the  efficiency  of  PE's,  T is  the  execution  time,  and  a is  a weighting 

index  of  execution  time  with  respect  to  efficiency.  The  reason  that  a is  necessary 

is  that  a range  of  measurements  with  different  degrees  of  emphasis  on  execution  time 

with  respect  to  efficiency  can  be  made.  Using  the  performance  measure  defined  above 

I we  can  do  some  comparative  study  of  the  overall  performance  evaluation  of  different 

j systems.  To  achieve  this  we  define  a relative  performance  measure  of  System  A with 

respect  to  System  B,  R,„,  to  be 
I Afi 


lb 
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AB 


A 

B 


P 


(A) 


wliich  will  be  used  repeatedly  in  comparing  the  relative  merits  of  various  systems. 


V.  SYSTEM  VARIATIONS  AND  PERFORMANCE  EVALUATIONS 

In  the  preceding  section  the  programs  of  the  general  circulation  model  were 
analyzed  based  upon  the  assumed  AP  organization  and  its  capabilities  presented  in 
Section  II.  Now  we  shall  examine  how  some  of  the  system  parameter  changes  affect 
the  overall  performance  of  the  system  processing  these  programs.  The  alternative 
systems  with  the  following  variations  are  presented: 

1.  f our-bis-parallel  arithmetic-logic  capabilities, 

2.  2048  PE's, 

3.  A096  PE's, 

4.  new  backup  storage  with  slower  speed, 

5.  new  backup  storage  with  faster  speed, 

6.  modularized  backup  storage, 

7.  backup  storage  banks  with  interleaving  capability,  and 

8.  addition  of  a high  speed  temporary  storage  (HSTS). 

We  shall  designate  the  system  with  the  above  system  parameter  changes  as 
Systems  2,  3,  ...,  and  9,  respectively,  with  the  original  system  as  System  1.  For 
each  of  the  alternative  systems  the  following  data  are  calculated  for  the  proces- 
sing of  the  general  circulation  model  programs. 

1.  new  execution  time  and  speedup  ratio  when  compared  with  the  original 
system, 

2.  new  PE  utilizations  and  efficiencies,  and 

3.  relative  performance  evaluation  with  respect  to  the  original  system. 

A.  Four-Bis-Parallel  Arithmetic-Logic  Capabilities 

In  the  following  paragraphs  we  consider  a four-bit-parallel  arithmetic  unit 
for  each  PE. 

If  the  four-bls-parallel  capability  is  provided  to  the  system,  yet  the  data 
transfer  rate  is  not  Increased  accordingly,  there  cannot  be  any  significant  Increase 
in  overall  nrocesslng  speed.  Therefore,  we  have  to  change  the  data  path  between 
PEAM  and  the  arithmetic-logic  unit  so  that  four  blses  of  data  can  be  accessed 
simultaneously.  This  provision  may  be  realized  through  the  use  of  four  identical 
associative  memories  with  proper  interconnections  between  them  and  the  arlthmetlc- 
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logic  unit. 

The  essential  hardware  requirement  for  £our-bls-parallel  add  and  subtract 
operations  Is  a four-bls-parallel  adder  due  to  their  simple  Iterative  read-add(sub- 
tract)-wrlte  sequence.  As  for  multiplications,  not  only  there  are  many  different 
algorithms,  but  also  each  algorithm  requires  different  hardware  setup.  Since  we  are 
trying  to  obtain  a balance  between  speed  gain  and  hardware  economy  In  providing 
four-bls-parallel  arithmetic- logic  operations,  before  we  finalize  the  design  of  the 
arithmetic  and  logic  unit,  we  examine  some  of  the  multiplication  algorithms.  Three 
algorithms  are  under  consideration:  direct  multiplication  scheme  used  by  TI's  SIMDA 
[5],  Booth  algorithm  used  In  bls-sequentlal  version  of  the  processor,  and  polynomial 
algorithm  used  In  Machado's  proposed  SPEAC  system  [6]. 

After  examining  and  comparing  these  three  multiplication  algorithms,  the  poly- 
nomial algorithm  Is  chosen  due  to  its  speed  advantage  and  less  storage  requirements. 

Based  upon  the  four-bls-parallel  capabilities  in  the  arithmetic-logic  unit  of 
PE's,  a complete  set  of  algorithms  for  all  the  necessary  arithmetic  operations  were 
developed  [4].  Using  the  same  timing  assumptions  as  we  used  for  bls-sequentlal 
operations  we  have  the  estimated  execution  time  for  the  four-bls-parallel  arithmetic 
operations  (Table  4).  Table  4 also  compares  the  execution  times  of  bls-sequentlal 
and  four-bls-parallel  arithmetic  operations  by  giving  the  speedup  factors. 


Table  4.  Execution  Time  of  Floating-Point  Arithmetic  Operations  (ysec) 


Operation 

Bis-Sequentlal 

Four-Bls-Parallel 

Speedup 

Factor 

Add 

Common 

126.7 

28.85 

4.39 

Field 

136.3 

52.5 

2.6 

Subtract 

Common 

126.7 

28.85 

4.39 

Field 

136.3 

52.5 

2.6 

Multiply 

Common 

107.2 

55 

1.95 

Field 

269.9 

95.80 

2.82 

j Divide 

Common 

253.9 

95.60 

2.66 

1 

1 

1 

Field 

269.9 

V5.80  2.82  j 

With  the  new  execution  times  for  these  various  operations,  we  can  calculate 
the  subtotal  and  total  execution  times  for  each  Individual  operations  and  the  en- 
tire programs.  The  first  row  of  Table  5 gives  the  speedup  factors  of  PART  I,  PART 
II,  and  OVERALL  programs  when  compared  with  the  original  system.  We  can  see  that 
the  speed  for  processing  the  general  circn'.ation  model  on  System  2 is  more  than 
doubled. 
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The  utilization  >>f  PE's  for  all  operations  remain  unchanged  in  System  2.  The 
new  PE's  efficiencies,  derived  from  the  new  execution  time  distribution  are  reduced 


Table  5.  Speedup  Factors 


SYSTEM  i- 

SPEEDUP  FACTOR  WITH  RESPECT  TO  SYSTEM 

PART  I 

PART  II 

OVERALL 

2 

2.12 

2.66 

2.22 

3 

2.05 

2.00 

2.04 

4 

4.26 

4.02 

4.08 

5 

0.91 

0.95 

0.92 

6 

1.06 

1.03 

1.05 

7 

1.04 

0.99 

1.03 

8 

1.14 

1.05 

1.12 

9 

1.06 

' 1.02 

1.05 

J 

j 

0 

2.86 

3.04 

2.90 

as  shown  In  second  row  of  Table  6.  This  reduction  results  from  the  great  decrement 
in  execution  time  of  arithmetic  operations  which  have  a high  utilization  of  0.8086, 


Table  6-  Comparison  of  PE  Efficiencies 


SYSTEM 

EFFICIENCY 

PART  I 

PART  II 

OVERALL 

1 

0.7626 

0.8059 

0.7715 

2 

0.7064 

0.8008 

0.7246 

3 

0.7757 

0.8070 

0.7830 

4 

0.7948 

0,8083 

0.7981 

5 

0.7467 

0.8042 

0.7594  j 

0.7704 

0.7065 

0.7788  1 

7 

0.7748 

0,8069 

0.7825  j 

8 

0,7857 

0.8078 

0,7911  1 

9 

0.7722 

0.8067 

0.7803 

10 

0.7713 

0.8063 

0.7632 

We  can  now  calculate  the  relative  performance  of  four-bis-parallel  processing 
with  respect  to  bls-sequential  processing.  82^^  in  Fig.  2 shows  the  relative  per- 
formance between  Systems  1 and  2 versus  a.  It  indicates  that  if  the  improvement  in 
execution  time  is  more  Important  than  in  PE  efficiency,  the  four-bis-parallel  arlth- 
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Figure  2.  Relative  performance  evaluation. 
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metlc-logic  technique  is  more  effective.  Even  when  a is  1 (the  efficiency  and  the 
execution  time  are  of  equal  importance)  the  relative  performance  measure  has  a value 
of  about  2. 

B.  Change  of  Number  of  PE's  and  Its  Effects 

We  are  going  to  examine  some  of  the  effects  when  the  capacity  of  the  associa- 
tive processor  is  doubled  or  quadrupled.  We  first  study  the  case  of  the  system  with 
2048  PE's.  Along  with  the  expansion  of  PE's  the  dimensions  of  both  the  backup  storage 
and  the  data  manipulator  have  to  be  changed  to  match  the  PE's  structure.  Since  the 
AP  capacity  is  doubled  to  2048,  we  can  now  finish  processing  of  any  complete  data 
set  in  two  iterations  instead  of  four.  Data  sets  are  now  grouped  into  two  groups. 
Since  the  discontinuity  between  groups  of  data  still  exists  all  the  operations  con- 
cerning patterns  2,  3,  and  4 remain  unchanged.  The  average  execution  time  for  each 
of  these  operations  have  changed  due  to  the  new  grouping.  Designating  this  AP  with 
2048  PE's  as  System  3 the  speedup  factors  can  be  found  in  Table  5. 

Utilization  of  PE's  in  System  3 has  changed  also  due  to  change  of  grouping  of 
the  data  sets.  Load  and  store  operations  now  take  fewer  basic  operations  to  achieve. 
As  a result,  most  of  the  new  utilizations  are  greater  than  the  original  ones.  The 
efficiencies  for  three  programs  in  System  3 are  given  in  Table  6. 

From  the  efficiencies  and  execution  times  of  three  programs  processed  by 
System  1 and  System  3 we  derive  the  relative  perfomance  evaluation,  (Fig.  2). 

System  4 is  the  system  with  4096  PE's  and  the  other  units  in  the  system  ex- 
panded proportionally.  The  total  execution  times  for  all  three  programs  are  cal- 
culated and  compared  with  those  of  System  1 (Table  5).  The  PE  efficiencies  for 
System  4 are  given  in  Table  6.  A rather  high  relative  performance  evaluation  of 
System  4,  (Fig.  2)  thus  results.  Its  value  exceeds  70  as  a reaches  3. 

C.  Change  of  Backup  Storage  Speed  and  Its  Effects 

The  speed  of  the  backup  storage  we  considered  for  System  1 is  500  nsec  for 
read  and  750  nsec  for  write,  without  considering  the  addressing  time.  We  shall  in 
the  following  analysis  change  the  speed  to  1 ysec-read  and  1.5  psec-write  for  System 
5 and  to  250  nsec-read  and  375  nsec-write  for  System  6.  We  shall  see  how  this  change 
of  the  backup  storage  speed  affects  the  execution  time,  PE  efficiencies,  and  over- 
all performance. 

The  speedup  factors  for  Systems  5 and  6 can  be  found  in  Table  5.  It  is  noted 
that  halving  the  storage  speed  brings  a substantial  slowdown  in  all  operations  while 
doubling  the  speed  brings  only  about  5%  speedup. 

The  PE  efficiencies  of  three  programs,  PART  I,  PART  II,  and  OVERALL,  processed 
in  System  5 are  lower  than  those  in  System  1 due  to  the  Increase  of  percentages  in 
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load  and  store  operations  while  the  PE  efficiencies  for  System  6 are  Increased 
(Table  6).  The  relative  performance  evaluations  of  Systems  5 and  6 are  plotted  In 
Fig.  2. 


D.  Modularization  of  Backup  Storage  and  Its  Effects 

In  Section  III  we  have  mentioned  the  discontinuity  of  data  sets  when  they  are 
stored  In  groups  of  blocks.  The  suggested  means  to  solve  this  problem  Is  the  crea- 
tion of  new  data  sets  to  speed  up  the  data  transfer  between  the  backup  storage  and 
PEAM.  As  a result  of  using  these  new  data  sets  a 24%  speedup  is  computed  for  all 
the  load  operations  performed  in  PART  I program  of  the  general  circulation  model. 

An  alternative  way  to  speed  up  the  loading  of  Patterns  2,  3,  and  4 data  sets  is 
to  modularize  the  backup  storage.  The  backup  storage  has  Q modules  with  equal  di- 
mensions. Their  vertical  dimensions  is  the  same  as  that  of  the  data  manipulator  and 
also  the  number  of  PE's.  A mask  register  is  associated  with  each  storage  module  in 

order  to  select  or  "screen"  the  words  to  be  read  out  or  written  into.  At  most  one 

ith  word  of  all  the  storage  modules  can  be  read  out  or  written  into  at  a time.  The 

words  thus  read  out  from  any  number  of  modules  can  then  be  manipulated  to  be  loaded 

in  a desired  format  into  PEAM.  Storing  data  from  the  PEAM  into  the  backup  storage 
modules  goes  through  the  same  procedure  in  reverse  order. 

All  other  operations  are  executed  in  exactly  the  same  way  as  in  System  1.  The 
speed  comparison  between  System  1 and  this  system  with  the  modularized  backup  stor- 
age, designated  as  System  7,  is  given  in  Table  5.  The  consequent  changes  in  execu- 
tion-time distributions  contribute  to  slightly  increase  in  PE  efficiencies  (Table  6). 
The  relative  evaluation  of  System  7 is  plotted  in  Fig.  2. 

E.  Backup  Storage  Banks  with  Interleaving  Features  and  Its  Effects 

In  using  an  interleaving  system  to  process  the  general  circulation  model,  we 
do  not  change  either  the  data  structure  or  the  programs  used  in  System  1.  It  affects 
the  execution  time  of  load,  store,  multiplicate  and  temporary  store  operations. 

The  total  execution  times  for  this  system.  System  8,  are  calculated  and  com- 
pared with  those  of  System  1 (Table  5).  From  Table  5 we  see  that  the  improvement 
in  total  execution  time  in  this  system  with  interleaving  BSB's  is  an  excellent  12% 
over  System  1,  even  though  the  combined  execution  time  of  load,  store,  temporary 
store,  and  multiplicate  operations  take  only  13.425%  in  the  original  system  for  the 
OVERALL  program.  This  speedup  is  also  reflected  in  the  calculation  of  PE  efficien- 
cies. As  the  data  transfer  type  of  operations  take  less  portion  of  the  total  exe- 
cution time  to  perform,  the  arithmetic  operations  which  have  higher  PE  utilization 
now  take  larger  percentage  of  the  total  time.  This  boosts  the  PE  efficiencies 
(Table  6).  The  plot  of  the  relative  perfo. nance  evaluation  of  System  8 with  re- 


6-13 


spect  to  System  1|  ^gj^»  found  in  Fig.  2. 

F.  Addition  of  A High  Speed  Temporary  Storage  and  Its  Effects 

Here  we  present  a system  with  a separate  storage  unit,  a high-apeed  temporary 
storage  (HSTS) , used  to  handle  the  temporary  store  operations  and  also  used  as  a 
buffer  between  the  backup  storage  (through  the  data  manipulator  or  bypassing  it) 
and  PEAM.  The  speed  of  this  high-speed  temporary  storage  is  compatible  to  that  of 
the  PE. 

The  comparison  of  subtotal  and  total  execution  times  between  System  1 and 
System  9 is  given  In  Table  5.  Note  that  the  speed  Improvement  of  the  OVERALL  pro- 
gram in  System  9 over  System  1 is  about  5%,  a very  significant  gain,  considering 
that  the  number  of  operations  with  improved  execution  time  by  the  use  of  HSTS  is 
only  12.02%  of  all  the  operations. 

PE  efficiencies  are  increased  in  System  9 as  compared  to  System  1 because  the 
execution  times  in  performing  load  and  store  operation  are  reduced  (Table  6).  The 
relative  performance  evaluation  of  System  9 with  respect  to  System  1.  Rgi  , does  not 
have  large  values  as  shown  in  Fig.  2. 

G.  Storage  Requirement  and  Auxiliary  Storage  Unit 

When  every  data  set  is  too  large  in  size  to  be  processed  at  one  time  as  in 
this  weather  computation  problem  with  the  assumed  organization,  there  are  two  kinds 
of  processing  schemes:  the  complete  data  set  processing  scheme  and  the  complete  pro- 
gram processing  scheme.  The  complete  data  set  processing  scheme  is  such  a design  of 
program  flow  that  every  data  set  is  completely  processed  by  each  subprogram  before 
going  through  the  next  subprogram.  On  the  other  hand,  a complete  program  processing 
scheme  is  so  designed  that  a segment  (i.e.,  group)  of  the  data  set  is  processed  by 
the  entire  program  before  the  next  segment  of  data  set  is  processed.  The  result  of 
a detailed  analysis  of  all  subprograms  and  their  storage  requirements  for  both 
schemes  is  summarized  in  Table  7 . 

From  Table  7 we  see  that  the  sizes  of  the  backup  storage  required  to  pro- 
cess the  general  circulation  model  are  160K  and  79K  in  the  complete  data  set  proces- 
sing scheme  and  the  complete  program  processing  scheme,  respectively,  without  the 
use  of  the  temporary  storage.  When  the  size  of  the  grid  system  becomes  larger,  say, 
doubled  in  both  horizontal  and  vertical  dimension,  the  size  of  the  backup  storage 
increases  rapidly  (277K  and  115K)  and  its  access  speed  may  be  slowed  down  consider- 
ably. The  use  of  an  auxiliary  storage  unit  is  thus  considered. 

An  APL  simulation  program  [4]  is  written  to  simulate  the  data  transfer  activi- 
ties between  the  backup  storage  and  the  disk.  Various  sizes  of  the  backup  storage 
are  used  in  the  simulation  program.  From  the  simulation  we  see  the  rapid  decrease 
in  the  number  of  roll-in  and  roll-out  operations  required  as  the  size  of  the  backup 
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Table  7.  Storage  Requirement  for  the  General  Circulation  Model 


'processiS&---®-I^^e 

SCHEME 

ONE  STORAGE 

SEPARATE  STORAGE 

Backup  Storage 

Backup  Storage 

Temporary 

Storage 

Total 

Complete  Data  Set 
Processing  Scheme 

160K 

156K 

lOK 

166K 

Complete  Program 

1 Processing  Scheme 

79K 

75K 

lOK 

85K 

storage  Increases,  especially  when  the  size  of  the  backup  storage  is  small.  When 

the  size  of  the  backup  storage  reaches  43K  words,  48  roll-in  and  36  roll-out  opera-  j 

tions  are  required  and  they  remain  constant  for  larger  backup  storage  sizes.  This 

total  of  84  roll-in  and  roll-out  operations  account  for  the  roll-ins  and  roll-outs  ’ 

of  the  twelve  residing  data  sets  at  the  beginning  and  the  end  of  each  updating  cycle, 

respectively.  Thus,  if  an  extra  36K  words  capacity  is  added  to  the  backup  storage 

no  roll-in  and  roll-out  operations  are  necessary.  This  agrees  with  the  backup  ! i 

storage  requirement  for  the  general  circulation  model  when  processed  by  the  complete  ( 

program  processing  scheme,  namely,  a maximum  of  79K  words  are  required  for  the  back-  \ 

up  storage  without  the  use  of  the  auxiliary  storage  unit.  : 


VI.  A MORE  COST-EFFECTIVE  ASSOCIATIVE  PROCESSOR  SYSTEM 

In  Section  V we  have  presented  eight  different  systems  and  showed,  in  each  of 
them,  how  the  system  parameter  change  affects  the  overall  performance.  However, 
each  of  these  system  parameter  changes  was  concentrated  in  only  one  component  of  the 
entire  system.  Three  of  these  eight  system  variations  were  on  the  associative  pro- 
cessing elements  and  five  on  the  backup  storage.  In  this  section  we  try  to  compare 
the  advantages  and  disadvantages  of  these  systems  and  then  combine  the  merits  of 
these  systems  in  order  to  arrive  at  a more  cost-effective  system  than  the  assumed 
system  presented  in  Section  II. 

A.  Comparison  of  the  Cost-Effectiveness  of  Alternative  Systems 
. Associative  Processing  Elements 

Three  systems.  Systems  2,  3,  and  4 mentioned  in  Section  V dealt  with  altera- 
tions of  the  capability  and  the  number  of  the  associative  processing  elements  in  the 
system.  Among  these  the  four-bls-parallel  processing  capability  affects  only  the 
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hardware  of  PE's  leaving  the  rest  of  the  system  intact.  But  in  the  cases  of  the 
other  two  alternatives,  the  sizes  of  other  components  in  the  system  change  along 
with  the  size  change  of  the  associative  processing  elements.  A cost  analysis  on 
these  two  alternatives  [4]  show  that  System  3,  with  2048  PE's,  and  System  4,  with 
4096  PE's,  have,  respectively,  a cost  of  double  and  quadruple  of  that  of  System  1 
and  the  overall  cost  of  System  2 is  less  than  double  of  that  for  System  1. 

Thus,  from  the  cost  analysis  and  the  speedup  factors  given  in  Table  5 for 
Systems  2,  3,  and  4,  it  seems  that  System  2 is  most  favorable.  Table  6 indicates 
that  the  PE  efficiencies  for  Systems  3,  and  4 are  a little  higher  than  that  for 
System  2 in  processing  this  weather  problem,  but  in  applications  where  the  sizes  of 
the  data  sets  being  processed  are  not  as  large  as  the  capacity  of  PE's  the  efficiency 
will  become  much  smaller.  In  short.  System  2 is  relatively  more  cost-effective. 

2.  The  Backup  Storage  Unit 

There  are  five  variations  on  the  speed,  the  capability,  and  the  structure  of 
the  backup  storage  unit,  resulting  in  five  different  systems.  Systems  5,  6,  7,  8,  and 
9.  In  considering  the  cost  factors  of  these  systems  in  comparison  with  System  1,  it 
is  apparent  that  System  5 is  the  only  system  which  is  less  costly  than  System  1 be- 
cause it  has  slower  speed.  System  7 and  8 have  basically  the  same  memory  modules 
but  with  different  accessory  equipments  such  as  masking  control  in  System  7 and 
Interleaving  control  in  System  8.  System  9 has  the  largest  storage  requirement  in 
terms  of  overall  storage  size.  If  we  process  the  general  circulation  model  programs 
in  a complete  program  processing  scheme.  Systems  5,  6,  7,  and  8 would  need  only  a 
total  of  79K  words  while  System  9 would  need  75K  words  of  backup  storage  and  lOK 
words  of  HSTS  (Table  7 ).  With  the  speed  of  HSTS  compatible  to  that  of  the  associ- 
ative memory  System  9 evidently  is  much  more  costly  than  the  others. 

It  may  be  difficult  for  us  to  have  a more  precise  cost  comparison  among  these 
systems  without  going  into  implementation  details.  On  the  other  hand,  it  may  not  be 
necessary  for  us  to  have  a more  precise  cost  comparison  to  determine  which  of  these 
systems  is  the  most  cost-effective  one.  From  Tables  5 and  6 we  can  see  that  System 
8 demonstrates  the  best  performance  in  execution  time  in  processing  the  general  cir- 
culation model  and  also  it  improves  the  PE  efficiency  from  0.7715  in  the  original 
system  to  0.7911.  It  seems  that  despite  the  difficulty  in  having  a very  precise 
absolute-cost  comparison  among  Systems  5,  6,  7,  8,  and  9,  it  is  reasonable  to  choose 
System  8 for  the  improvement  of  the  backup  storage  over  the  origins  system. 

B.  Examination  of  a Cost-Effective  System 

We  shall  now  examine  how  the  new  system,  designated  as  System  10,  with  the 
combined  Improvements  from  System  2 and  System  8,  performs  in  implementing  the  gen- 
eral circulation  model.  The  operation  distribution  remains  the  same  as  in  System  1 
since  there  is  no  change  in  programming.  The  total  execution  times  for  PART  I, 
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PART  II,  and  OVERALL  program  are  92833.94  psec,  258462.15  psec,  and  1186801.5  psec, 
representing  speedup  ratios  over  System  1 of  2.86,  3.04,  and  2.90,  respectively 
(Table  5). 

We  may  look  at  the  execution  time  from  another  point  of  view.  As  done  in 
Section  IV,  total  execution  times  are  analyzed  according  to  the  utilization  of  the 
major  components  in  the  system.  The  associative  processing  elements  are  kept  busy 
in  all  the  operations  so  it  has  a 100%  component  utilization.  Only  8.00%  of  the 
total  time  is  spent  on  the  data  transfer  operation  between  PE's  and  the  backup 
storage,  either  through  the  data  manipulator  or  bypassing  it  (Table  2).  Again,  the 
decrease  in  this  figure  from  that  for  System  1 is  due  Ito  a tremendous  speedup  in 
data  transfers  by  Interleaving  the  blses  when  transferred  in  and  out  of  the  backup 
storage.  This  low  utilization  of  the  backup  storage  suggests  a need  for  further 
improvement  in  component  utilization.  To  achlev^e  this  data  sets  to  be  processed  in 
the  associative  processing  elements  may  be  stored  at  different  levels  of  the  memory 
hierarchy  originally  and  can  be  brought  to  the  unit  physically  right  next  to  the 
PE's.  The  time  required  in  the  more  complicated  data  management  can  be  overlapped 
with  the  PE  processing  time.  Even  some  of  the  data  manipulating  functions  can  be 
performed  either  before  the  data  sets  are  actually  being  loaded  into  the  PEAM  or  if 
necessary,  after  they  are  outputted  from  PEAM  and  before  they  are  stored  back  into 
the  storage.  More  sophisticated  controls  and  detection  of  special  features  of  the 
instruction  sequences  should  be  provided  for  this  more  efficient  processing  tech- 
nique in  order  to  prevent  any  type  of  conflicts  among  the  components. 

’ Table  2 also  shows  a quite  significant  increase,  about  20%,  in  the  use  of  the 
data  manipulator  when  compared  with  System  1.  The  new  PE  efficiencies  in  processing 
the  three  programs  of  the  general  circulation  model  on  System  10  are  0.7713,  0.8063, 
and  0.7632,  respectively  (Table  6).  A slight  decrease  in  efficiency  is  evident  in 
PART  I and  OVERALL  programs  where  the  percentages  of  execution  time  in  arithmetic 
operations  (having  a high  PE  utilization  of  0.8086)  dropped.  The  relative  perform- 
ance evaluation  R^^q  of  System  10  with  respect  to  System  1 ranges  from  1.29  to  a 
very  respectable  23.88  as  a varies  from  0.25  to  3.0  (Fig.  2). 

The  efficiencies  of  the  backup  storage  and  the  data  manipulator  for  Systems  1 
and  10  are  summarized  in  Table  8.  The  efficiencies  of  System  10  are  Improved  sub- 
stantially over  those  of  System  1. 

C.  Further  Consideration  of  a Cost-Effective  System 

Consider  that  a disk  unit  is  added  to  the  system  and  dual  control  units  are 
provided  so  that  concurrent  operation  both  in  the  PE's  and  in  the  backup  storage  and 
the  disk  unit  can  be  performed.  Adding  this  disk  unit  has  twofold  advantages:  the 
utilization  of  the  backup  storage  is  improved  and  the  size  of  the  backup  storage  can 
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Table  8.  Efficiencies  of  Backup  Storage  and  Data 
Manipulator  In  System  1 and  System  10. 


SYSTEM 

COMPONENT 

SYSTEM 

PART  I 

PART  II 

OVERALL 

BACKUP 

STORAGE 

I 

0.5972 

0.7672 

0.6153 

10 

0.6104 

0.7751 

0.6303 

DATA 

MANIPULATOR 

1 

0.4546 

0.4112 

0.4539 

10 

0.4746 

0.4376 

0.4743 

be  reduced.  From  the  result  of  Section  V we  have  already  known  the  number  of  roll- 
in  and  roll-out  operations  required  for  the  system  with  certain  size  of  the  backup 
storage  to  process  the  general  circulation  model  program.  Our  attempt  here  is  to 
find  the  optimal  size  of  the  backup  storage  in  the  most  efficient  system. 

Let  us  assume  that  an  Alpha  Data  16"  disk  unit  is  used.  It  has  an  average 

■ 7 

latency  time  of  16.8  msec  and  a flow  rate  of  10  bit/sec  approximately.  It  takes 
' about  3.2  msec  to  perform  a roll-in  or  roll-out  operation.  The  approximate  time 

' required  to  accomplish  all  the  roll-in  or  roll-out  operations  is  then  the  number  of 

[ roll-in  and  roll-out  operations  times  20  msec.  The  optimal  size  of  the  backup  stor- 

age  should  be  such  that  the  roll-in  and  roll-out  operations  do  not  increase  the 
f total  execution  time.  That  is,  the  roll-in  and  roll-out  operations  should  overlap  as 

t much  as  possible  with  the  time  when  the  backup  storage  is  idle.  From  Table  2 there 

[ is  about  1120  msec  during  which  period  the  backup  storage  is  idle.  Thus  the  maximum 

I number  of  roll-in  and  roll-out  operations  is  1120/20  = 56.  By  checking  Fig.  4 we 

find  out  that  the  minimum  number  of  roll-in  and  roll-out  operations  is  84  when  all 
12  residing  variables  data  sets  (48K  words)  are  stored  on  disk  and  the  backup  stor- 
age  has  a size  of  43K  words.  If  we  add  extra  12K  words  to  the  backup  storage  for 
three  residing  variables  and  the  rest  nine  remain  stored  on  the  disk  then  the  number 
of  roll-in  and  roll-out  operations  is  exactly  56.  Thus,  for  implementing  the  general 
circulation  model  on  such  a system  with  four-bis-parallel  capabilities  and  inter- 
, leaving  backup  storage  banks,  the  optimal  size  of  the  backup  storage  is  43K  + 12K  = 

55K,  provided  that  the  complete  program  processing  scheme  is  used. 

The  reduction  of  the  size  of  the  backup  storage  from  79K  word:  in  a system 
j without  a disk  unit  to  55K  words,  and  about  30%  reduction,  may  not  be  significant 

i in  terms  of  hardware  cost.  But  when  the  grid  system  used  in  the  general  circulation 

model  becomes  denser,  say,  the  numbers  of  grid  points  on  the  latitudinal  and  the 
longitudinal  lines  are  doubled  there  could  be  much  greater  savings  in  the  backup 

I 

I 
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D.  A Cost-Effective  Associative  Processor  Organization 

In  sunmarlzlng  the  result  of  the  analyses,  a final  system.  Is  presented  here. 
Figure  3 gives  a more  detailed  diagram  of  the  optimal  system.  The  descriptions  of 
the  system  components  are  given  below; 

1.  Control  Unit:  This  unit  stores  the  main  programs,  executes  the  instruc- 
tion sequence,  performs  some  sequential  arithmetic  operations  and  controls  other 
components  in  the  system  by  sending  out  appropriate  control  signals  to  them.  Dual 
control  capability  must  be  provided  in  this  unit  so  that  the  concurrent  operations 
of  data  transfer  between  the  backup  storage  banks  and  the  disk  unit,  and  executing 
arithmetic,  search,  or  other  operations  in  PE's  alone  can  be  successfully  achieved. 
This  dual  control  units  supervise  all  the  activities  and  prevent  any  conflicts  from 
occurring. 

2.  Input/Output  Unit:  A disk  unit  with  an  average  latency  time  of  16.8msec 
is  used  as  the  auxiliary  storage  unit.  Input/Output  unit  receives  the  commands  from 
the  control  unit  and  performs  data  transfers  between  the  disk  unit  and  the  backup 
storage  without  sacrificing  the  total  execution  time. 

3.  Interleaving  Backup  Storage  Banks:  There  are  four  backup  storage  banks, 
each  having  a size  of  14K  words.  When  reading  or  writing  data  bises  out  of  or  into 
Che  backup  storage  banks  in  an  interleaving  manner  the  effective  read  and  write 
times  are  150  nsec/bls  and  200  nsec/bls,  respectively.  This  provision  increases  the 
overall  system  performance  to  a quite  substantial  extent.  When  the  total  execution 
time  for  processing  the  general  circulation  model  programs  is  considered,  it  has  an 
improvement  of  about  12%.  When  PE's  are  processing  some  data  sets  without  the  use 
of  this  component,  the  backup  storage  banks  can  load  and  unload  data  sets  from  and 
to  the  disk.  This  kind  of  concurrent  operation  Increases  the  utilization  of  the 
system  components  and  thus  Improves  the  overall  system  efficiency. 

4.  Data  Manipulator:  In  order  to  have  an  effltient  parallel  processor  some 
kind  of  data  manipulating  unit  must  be  included  in  the  system  otherwise  the  time 
spent  on  preparing  data  sets  to  be  processed  may  well  offset  the  time  saved  by 
parallel  processing.  The  separate  data  manipulator  provided  in  this  system  not  only 
speeds  up  data  preparation  but  also  adds  more  flexiblllt''  to  the  choice  of  data 
source  and  destination.  A very  competent  set  of  data  manipulating  functions  are 
built  into  this  unit  to  enhance  its  performance.  A total  of  about  14%  of  the  total 
execution  time  is  spent  on  operations  Involving  this  data  manipulator  when  the  gen- 
eral circulation  model  is  Implemented  on  this  system.  Shift  and  multiplicate  oper- 
ations are  greatly  used  in  this  weather  problem. 
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5.  Associative  Processing  Elements:  After  the  analysis  on  tiie  execution  time 
speedup  ratios  it  is  evident  that  it  is  very  advantageous  to  equip  the  PE's  with 
f our-bis-paral lei  processing  capabilities.  The  overall  speed  improvement  is  more 
than  100%  as  a result  of  this  change.  The  processing  elements  associative  memorv 
(PEAM)  can  be  implemented  by  four  smaller  PEAM's  each  with  IK  words.  The  data  sets 
are  stored  in  these  PEAM's.  One  bis  of  data  is  accessed  from  each  of  the  four 
PEAM's  simultaneously  to  be  processed  by  the  arithmetic-logic  unit.  The  read  and 
write  time  of  these  PEAM's  are  100  nsec/bis  or  word  and  150  nsec/bls  or  word,  re- 
spectively. There  are  16  bises  of  TS  for  temporarily  storing  mask  conditions,  re- 
sults of  logic  or  search  operations. 

VII  CONCLUSIONS 

A cost-effective  system  for  weather  computations  was  determined  after  some 
comparisons  were  made  among  all  the  system  alternatives.  The  comparisons  included 
the  cost  factors  (in  terms  of  hardware  complexity),  total  execution  time,  and  PE 
efficiency.  It  has  1024  PE's  equipped  with  f our-bis-paral lei  processing  capabilities 
and  content-addressability,  a separate  data  manipulator,  four  interleaving  backup 
storage  banks,  a control  unit  with  dual  control  capability  and  a disk  unit.  The 
implementation  of  the  general  circulation  model  on  this  optimal  system  was  then 
analyzed.  This  system  was  again  compared  against  the  original  system.  The  total 
throughput  is  increased  by  almost  three  times.  A system  efficiency  evaluation  which 
included  the  utilizations  and  efficiencies  of  all  three  major  system  components , the 
cost  factor,  and  the  total  execution  time  was  made  for  the  two  systems.  There  is 
about  10%  Increase  in  system  efficiency  in  the  optimal  system. 

The  whole  project  required  very  tedious  and  laborious  work  of  studying 
thoroughly  the  particular  application  problem  and  its  program,  rewrltting  the  pro- 
gram into  parallel  processing  program,  gathering  operational  statistics,  developing 
detailed  algorithms  for  arithmetic  operation  (both  bis-sequential  and  four-bis- 
parallel),  analyzing,  evaluating,  and  comparing  system  performance,  and  finally  de- 
termining an  optimal  system.  The  completeness  of  the  orip  nal  document  of  the  gen- 
eral circulation  model  facilitated  the  validity  of  this  undertaking. 
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AAPL:  AN  ARRAY  PROCESSING  LANGUAGE 

JOHN  G.  MARZOLF 

Department  of  Electrical  and  Computer  Engineering 
Syracuse  University 
Syracuse,  New  York  13210 

Abstract  — AAPL  is  .1  dialect  of  APL  designed  to  be  more  amenable  to  compila- 
tion than  the  standard  version  of  APL.  The  principal  differences  include  the  use  of 
name  prefixes,  the  ability  to  accept  a limited  character  set  for  denoting  the  primi- 
tive functions,  some  variations  and  restrictions  on  the  use  of  the  program-branching 
primitive,  and  some  additional  I/O  primitives.  The  reasons  for  each  of  these  modi- 
fications are  discussed  in  detail,  as  well  as  the  implications  for  transportability 
between  the  two  dialects.  An  implementation  of  AAPL  has  been  undertaken  for  the 
STARAN  Associative  Processor.  An  outline  of  this  implementation  and  a progress 
report  on  the  work  is  presented. 


INTRODUCTION 

APL  as  currently  defined  by  the  APL/360  implementation  (see  [1]  and  [2])  seems 
to  be  a natural  candidate  for  a high-level  language  for  SIMD-type  parallel  proces- 
sors [3]-[5].  For  a number  of  reasons,  however,  it  does  not  appear  that  it  can  be 
conveniently  compiled.  For  Instance,  the  context-sensitive  nature  of  a number  of 
primitive  symbols  leaves  their  semantics  ambiguous  until  execution  time.  Specifi- 
cally, there  are  a group  of  primitive  symbols  which  are  used  to  denote  two  completely 
different  functions  depending  on  the  number  of  arguments  supplied  with  the  symbol. 

An  example  would  be  the  cross  (ordinary  multiplication  sign),  which  can  be 
used  monadically  (i.e.,  with  only  a right  argument)  to  represent  the  signum  func- 
tion, or  it  can  be  used  dyadically  (i.e.,  with  both  a left  and  right  argument)  to 
denote  the  multiplication  function.  In  any  given  context  the  precise  function  in- 
tended can  be  determined  by  examining  the  source  code  to  the  left  of  the  symbol.  If 
there  is  some  primitive  scalar  function  on  the  left,  then  the  cross  has  no  left 
argument  and  hence  is  the  signum  function.  If  there  is  a right  parenthesis  or  a 
number  to  the  left  of  the  cross,  then  it  is  known  to  be  dyadic  and  thus  is  the 
multiplication  function.  For  these  cases  the  meaning  is  uniquely  determined  when 
the  source  code  is  entered.  Such  an  arrangement  allows  compilation,  provided  one 
omits  consideration  of  the  memory  management  required  for  storage  of  the  result. 

The  complication  sets  in  when  a name  or  identifier  appears  to  the  left  of  the 
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cross.  There  Is  no  way  of  knowing,  prior  to  the  actual  execution  of  the  statement, 
whether  this  name  will  represent  (at  execution  time!  a variable  value  or  a monadic 
defined  function  call  - and  that  makes  all  the  difference.  Another  difficulty  in 
compiling  APL  stems  from  the  absence  of  declaration  statements  in  the  language. 

This  makes  memory  management  a very  complicated  process. 

One  obvious  response  to  these  difficulties  is  to  run  APL  interpretat ively . 

Not  only  does  this  solve  the  problems  mentioned,  but  it  also  buys  a whole  host  of 
little  extras  that  are  very  convenient  for  interactive  programming.  On  the  other 
hand,  it  entails  a certain  loss  of  execution  efficiency.  This  is  counter-productive 
to  the  increased  computational  throughput  expected  from  parallel  processing. 

The  solution  that  is  proposed  here  is  to  introduce  a dialect  of  APL  (to  be 
called  AAPL,  for  'An  Array  Processing  Language')  which  can  be  more  readily  compiled, 
yet  will  remain  as  close  as  possible  to  the  basic  structure  of  standard  APL.  This 
permits  parallel  processing  programs  to  be  interactively  written,  tested  and  debug- 
ged on  existing  APL  systems,  and  then  transferred  to  the  parallel  processing  systems 
for  production  use.  It  also  provides  the  parallel  processing  programmers  with  a 
tested  set  of  array  oriented  algorithms  that  have  been  developed  by  the  APL  program- 
mers . 


THE  DESIGN  OF  AAPL 

There  appear  to  be  two  solutions  to  the  problem  of  using  the  same  symbol  to 
represent  two  different  functions,  namely  (1)  change  one  of  the  symbols,  or  (2)  pro- 
vide naming  conventions  which  explicitly  identify  the  class  of  a name  used  on  the 
left  of  the  ambiguous  symbol.  The  first  solution  is  the  obvious  one,  but  it  adds 
the  additional  burden  of  having  to  provide  more  primitive  symbols  - perhaps  to  the 
extent  of  creating  a symbol  set  that  will  become  unwieldy.  This  objection  could  be 
removed  by  a variation  employing  reserved  words  for  certain  of  the  primitive  func- 
tions. In  this  case  there  is  the  more  serious  objection  that  it  would  be  difficult 
to  transport  programs  between  the  two  dialects  of  APL,  For  this  reason  the  second 
of  the  proposed  solutions  was  chosen  for  AAPL.  This  also  solves  the  related  problem 
of  detecting  the  syntax  error  in  an  attempted  assignment  of  a value  to  a niladic 
function  name  or  a label. 

All  names  in  AAPL  are  given  alphabetic  prefixes  which  specify  the  name-class 
of  the  object  identified.  There  are  five  name-classes,  and  each  is  distinguished  by 
a two  letter  prefix  as  shown  in  Table  I.  This  means  that  all  AAPL  names  are  a mini- 
mum of  three  characters  long.  The  first  two  must  be  a proper  prefix  and  the  remain- 
ing characters  should  be  chosen  according  to  the  ordinary  naming  rules  of  APL.  Such 
a procedure  causes  AAPL  names  to  form  a subset  of  APL  names.  Provided  the  names 
used  in  standard  APL  programs  are  chosen  from  that  subset,  all  programs  can  be  in- 
terchanged without  alteration  between  the  two  dialects. 
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The  selection  of  a two  letter  prefix  scheme  (rather  than  a one  letter  arrange- 
ment) was  related  to  the  desire  of  freeing  AAPL  from  the  I/O  device  restrictions  Im- 
posed by  the  ordinary  APL  symbol  set.  In  discussing  this  problem  it  should  be  noted 
that  AAPL  Is  Intended  to  be  a dialect  of  APL,  and  hence  should  differ  from  it  as 
little  as  possible.  On  these  grounds  it  was  decided  that  the  AAPL  symbol  graphics 
would  be  those  of  standard  APL.  However,  the  AAPL  compiler  would  be  designed  to 
accept  mnemonics  as  well  as  the  standard  symbols,  since  this  would  broaden  the  base 
of  I/O  devices  that  could  be  used  with  the  system. 

There  have  already  been  a number  of  proposals  for  such  a set  of  mnemonics  [6]- 
[8],  but  they  generally  employ  a preceding  escape  character  to  differentiate  the 
mnemonics  from  a similarly  constructed  APL  name.  In  addition,  the  escape  sequence 
is  designed  to  be  processed  by  the  system  input  routine.  This  means  that  the  con- 
version from  the  supplied  mnemonic  to  the  proper  internal  representation  is  made 
wherever  the  escape  convention  is  encountered.  In  other  words,  if  the  escape  sequence 
were  used  within  a character  literal,  it  would  be  converted  by  the  system  to  the 
appropriate  internal  representation  of  the  graphic  for  which  it  was  the  mnemonic.  This 
is  a suitable  arrangement  provided  one  is  willing  to  allow  the  internal  character 
count  of  some  arrays  to  be  different  . rom  that  of  their  graphic  representations.  This 
is  an  anomaly  which  is  avoided  in  AAPL. 

There  are  no  mnemonic  escape  characters  used  in  AAPL.  If  the  input  is  coming 
from  a device  capable  of  generating  only  a subset  of  the  APL  symbols,  then  those  are 
the  only  symbols  the  device  can  enter  into  the  system.  What  AAPL  does  permit,  and 
which  is  not  permitted  in  standard  APL,  is  an  alternate  way  of  indicating  to  the 
compiler  what  precise  computation  is  intended  by  the  programmer. 

The  AAPL  programmer  may  replace  many  of  the  standard  APL  graphics  with  a two 
letter  mnemonic,  which,  because  of  the  prefixing  scheme  chosen,  cannot  be  confused 
with  a name.  When  these  mnemonics  are  entered  from  any  device  (including  a device 
capable  of  entering  the  full  APL  symbol  set)  they  are  entered  into  the  system  pre- 
cisely as  the  symbols  for  which  they  are  the  graphics  (not  as  the  symbols  for  which 
they  are  the  mnemonics).  The  difference  comes  when  the  AAPL  compiler  encounters 
them.  At  this  point  they  are  translated  into  the  proper  execution  code  according  to 
their  mnemonic  meaning. 

For  this  reason  not  every  APL  graphic  has  a mnemonic  representation,  but  only 
those  that  denote  an  executable  operation,  or  are  used  as  compiler  directives,  such 
as  the  lamp  to  indicate  a remark.  The  mnemonics  recognized  by  the  AAPL  compiler  are 
shown  in  Table  II.  They  are  all  two  letter  mnemonics,  except  for  the  letter  N which 
is  used  to  denote  the  hi-mlnus.  This  is  treated  as  an  exception  since  it  is  used  as 
part  of  a numeric  representation  to  denote  a negative  value,  and  is  analogous  to  the 
use  of  the  letter  E in  exponential  format.  In  addition,  the  ASCII  circumflex  and  the 
PL/1  logical  NOT  (hooked-minus)  are  considered  as  stylized  versions  of  the  hl-mlnus. 

In  cases  where  two  mnemonics  are  shown  for  a given  primitive,  they  are  so 
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provided  to  improve  the  readability  of  the  mnemonic  source  code,  but  they  may  be 
used  interchangeably.  The  Intended  meaning  is  determined  by  the  compiler  following 
the  same  procedures  it  would  use  if  the  primitive  graphic  had  been  employed. 

Using  this  set  of  mnemonics,  the  only  symbols  required  to  write  any  AAl’L  func- 
tion would  be  the  letters,  digits,  parentheses,  period,  quote,  and  space.  This  per- 
mits AAPL  programs  to  be  entered  from  virtually  any  I/O  device.  The  only  features 
not  provided  by  the  mnemonics  are  the  first-axis  functions  (for  rotate,  compress, 
expand,  reduction,  and  scan),  and  the  trace  and  stop  control  vectors.  The  omission 
of  the  first  axis  functions  is  not  serious  since  they  may  be  obtained  from  the  in- 
dexed versions  of  these  functions.  The  trace  and  stop  control  facilities  are  debug- 
ging aids,  and  it  was  not  considered  necessary  to  Include  them  in  a production  ori- 
ented system. 

Three  new  primitive  functions  have  been  added  to  allow  the  full  use  of  all 
available  I/O  devices.  These  primitives  are  not  assigned  graphics  from  the  standard 
APL  sjrmbol  set  so  as  not  to  conflict  with  any  future  assignments.  They  are  avail- 
able only  as  mnemonics.  There  is  one  input  function  (IN)  which  is  monadic  and  takes 
a two  component  vector  for  its  right  argument.  This  argument  specifies  a iile  num- 
ber and  a component  number  which  is  the  logical  identifier  of  a physical  device  and 
a specific  record.  The  assignment  of  a logical  Identifier  to  a given  physical  file 
is  made  by  one  of  the  I-beam  functions.  This  also  opens  the  file.  The  result  gen- 
erated by  the  input  function  is  the  value  of  the  data  object  identified  by  its  right 
argument . 

There  are  two  functions  provided  for  generalized  output;  OU  is  the  mnemonic 
for  bare  output  and  OT  denotes  terminated  output.  These  functions  are  identical 
except  for  a final  new-line  character  (carriage  return  plus  line  feed)  that  is  sup- 
plied by  the  system  at  the  end  of  each  OT  output  request.  Both  functions  are  dyadic. 
The  left  argument  specifies  a logical  file  and  component  (similar  to  the  file/com- 
ponent specification  of  the  input  function)  and  the  right  argument  provides  the  data 
object  to  be  output.  Like  other  APL  primitives,  the  output  functions  generate  a 
result,  which  in  this  case  is  t^e  value  of  the  right  argument.  In  other  words,  ig- 
noring the  physical  output  produced,  these  functions  act  as  if  they  were  the 
identity  function.  An  alternate  way  of  viewing  these  two  functions  is  as  a special- 
ized case  of  the  assignment  function  where  the  left  argument  is  the  logical  name 
of  a shared  variable  [9]. 

The  problem  of  memory  management  in  the  absence  of  dimension  t.eclarations  is 
solved  by  subterfuge.  Although  subsequent  versions  of  AAPL  may  wish  to  attack  this 
problem  directly,  the  present  version  solves  it  by  a get-space  routine  that  does  the 
job  at  execution  time.  This  means  that  there  is  not  a unique  correspondence  between 
the  variable  names  and  their  physical  memory  addresses.  Data  values  are  located 
through  a data  descriptor  table.  Once  some  experience  is  gained  with  this  imple- 


mentation  it  will  be  possible  to  determine  if  a better  solution  to  the  problem  is 
demanded . 

There  has  been  an  improvement  in  the  efficiency  of  the  branching  mechanism 
supplied  with  standard  APL.  Since  the  whole  question  of  a proper  set  of  control 
structures  for  APL  is  under  investigation  (see,  for  example,  [10]  and  [11])  the 
arrangement  described  here  should  be  seen  as  only  an  interim  solution.  Although  the 
GOTO  is  not  eliminated  (Indeed,  it  remains  the  kernel  of  the  whole  control  system) 
it  is  made  subject  to  a number  of  restrictions  designed  to  provide  more  efficient 
execution.  As  a by-product  these  restrictions  significantly  improve  one's  ability 
to  trace  the  flow  of  control  through  a program. 

There  are  only  three  types  of  syntax  allowed  when  using  the  branch  arrow.  It 
may  be  used 

(1)  with  a single  label  or  the  number  0, 

(2)  with  an  indexed  label  list,  or 

(3)  with  a single  label  or  the  number  0,  followed  by  the  mnemonic  IF, 
followed  by  any  AAPL  expression  that  evaluates  to  a 1 or  0. 

This  means  that  the  target (s)  of  any  branch  is  (are)  always  visible  at  the  source 
level.  Although  this  is  more  restrictive  than  the  ordinary  APL  usage,  it  avoids  the 
possibility  of  a variable  name  or  function  name  completely  obscuring  the  destination 
of  the  branch. 

The  indexed  label  list  mentioned  in  the  second  type  of  branch  is  constructed 
by  simply  juxtaposing  a number  of  labels  (or  the  number  0)  as  if  they  were  the  ele- 
ments of  a numeric  vector,  and  then  indexing  this  string.  This  is  the  format  re- 
quired by  the  AAPL  compiler,  but  it  is  not  permitted  in  APL.  Nonetheless,  its 
semantic  equivalent  may  be  easily  obtained  in  APL  by  catenating  the  labels,  enclos- 
ing them  in  parentheses  and  indexing  the  resulting  expression.  This  multiple  branch 
provides  the  "case  selection"  capability  used  by  structured  progranming  languages  to 
execute  one  of  a number  of  alternate  program  blocks. 

The  third  type  of  branch  uses  a new  primitive  (IF)  which  is  nothing  more  than 
the  compression  function  with  its  arguments  reversed,  together  with  the  restriction 
that  its  left  argument  must  be  a single  label  or  the  number  0.  Although  this  func- 
tion is  not  available  in  standard  APL  as  a primitive,  it  is  easily  introduced  as  a 
user  defined  function.  Indeed,  there  are  no  real  transportability  problems  between 
the  two  dialects  because  of  these  branching  restrictions.  All  that  is  required  is 
that  these  restdictions  also  be  followed  in  the  standard  APL  programs. 

THE  IMPLEMENTATION  OF  AAPL 

An  implementation  of  AAPL  is  in  progress  for  the  STARAN  Associative  Processor 
at  Rome  Air  Development  Center.  The  AAPL  compiler  is  itself  written  in  AAPL.  It 
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communicates  with  the  I/O  devices  through  a supervisor  module  written  In  MACRO-11 
assembly  code.  This  module  runs  on  a PDP-11  which  acts  as  the  sequential  control 
unit  for  STARAN.  The  supervisor  module  uses  the  basic  I/O  facilities  of  the  DOS-11 
batch  operating  system,  and  presents  the  AAPL  compiler  with  a source  program  in  a 
form  called  PCODE.  This  is  a print-code,  and  is  merely  an  extension  of  ASCII  to 
allow  for  the  APL  graphics,  including  the  overstrikes. 

The  AAPL  compiler  translates  the  PCODE  source  program  into  an  object  module  in 
a form  called  QCODE.  If  the  source  program  is  a function  definition,  then  the  ob- 
ject module  is  merely  stored  in  the  control  memory.  Otherwise  the  compiler  acts  as 
a load-and-go  system,  deleting  the  object  module  when  execution  is  complete. 

QCODE  is  the  AAPL  execution  code,  and  is  basically  a form  of  threaded  code 
[12].  The  QCODE  machine  is  a stack  oriented  virtual  machine  composed  of  two  main 
modules,  one  running  on  the  sequential  processor  (SP)  and  the  other  on  the  associ- 
ative processor  (AP).  There  is  also  an  interface  module  to  manage  the  inter- 
processor communications  via  the  interrupt  system  and  shared  memory  (which  is  actu- 
ally AP  control  memory  that  is  accessible  to  SP). 

The  system  attempts  to  overlap  as  much  as  possible  of  the  SP  and  AP  execution. 
The  SP  module  fetches  the  object  code,  decodes  it,  performs  the  necessary  housekeep- 
ing, and  makes  a call  to  AP  for  an  array  operation.  While  AP  is  satisfying  this 
request,  SP  proceeds  to  the  next  object  code. 

The  SP  module  consists  of  about  100  routines,  of  which  about  70  have  been 
written  and  tested.  These  routines  have  all  been  written  in  MACRO-11.  The  AP  mod- 
ule is  written  in  APPLE,  which  is  the  assembly  language  for  the  STARAN  as  -dative 
processor.  Only  a few  of  these  routines  have  been  completed. 

The  Initial  tests  on  the  system  have  used  a sequential  simulation  in  place  of 
the  AP  module.  While  it  is  not  possible  at  this  time  to  provide  detailed  perform- 
ance statistics,  preliminary  tests  using  a stand-alone  PDP-11/A5  are  extremely  en- 
couraging. For  instance,  the  AAPL  branch  outperforms  the  APL  branch  (running  on  an 
IBM  370/155)  by  better  than  4-1.  This  is  an  actual  elapsed  time  measurement  without 
an  adjustment  for  the  different  intrinsic  speeds  of  the  two  machines. 


TABLE  I. 

NAME  PREFIXES 

Prefix 

Name  Class 

VA 

Variable 

LA 

Label 

NF 

Nlladlc  function 

MF 

Monadic  function 

DF 

Dyadic  function 

4 


1 

A 


1 
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TABLE  II. 


AAPL  MNEMONICS 


Graphic  Name 


Mnemonic  Graphic  Name 


Mnemonic 


+ Plus  PL 

Minus  MI 

X Times  (Slgnum)  TI,SG 

Divide  DV 

* Exponentiate  XP 

Maximum  (Celling)  MX,CE 

^ Minimum  (Floor)  MN,FL 

I Residue  (Absolute  Value)  RS,AB 

® Logarithm  LG 

! Factorial (Binomial  Coef)  FA,BC 

o Circular  Fns  (Pi  Times)  Cl, PI 

< Less  than  LT 

< Less  than  or  Equal  LE 

= Equal  EQ 

> Greater  than  or  Equal  GE 

> Greater  than  GT 

y Not  Equal  NE 

/>  And  AN 

V Or  OR 

■A  Nand  NA 

V-  Nor  NR 

'V  Logical  Not  NT 

? Question  Mark  QU 

, Catenate  (Ravel)  CA,RA 

0 Rho  RH 

\ Iota  10 

Epsilon  EP 

Transpose  TR 

Rotate  RT 


+ 

Take 

TA 

I 

Drop 

DR 

A 

Grade  Up 

GU 

Grade  Dovm 

GD 

/ 

Compression  (Reduction) 

CM.RD 

\ 

Expansion  (Scan) 

XN.SC 

1 

Base  Value 

BV 

T 

Representation 

RP 

Execute /Evaluate 

EX 

Format 

FM 

Matrix  Divide 

MD 

Assign/Is 

IS 

[ 

Left  Bracket 

LB 

] 

Right  Bracket 

RB 

f 

Semicolon 

SM 

I 

I-Beam 

IB 

Quad 

QD 

□ 

Quote-Quad 

QQ 

Input 

IN 

Output-Bare 

OU 

Output-Terminated 

OT 

e 

Null/Outer  Product 

OP 

V 

Del 

DL 

Locked  Del 

LD 

-► 

Go  To 

GO 

IF 

IF 

: 

Colon 

CL 

A 

Lamp /Remark 

RM 

Hi-mlnus 

N 
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MISSION 

of 

Roiw  Air  Development  Center 


RADC  plans  and  conducts  research,  exploratory  and  advanced 
development  programs  in  command,  control,  and  communications 
(C^)  activities,  and  in  the  areas  of  information  sciences 
and  intelligence.  The  principal  technical  mission  areas 
are  communications,  electromagnetic  guidance  and  control, 
surveillance  of  ground  and  aerospace  objects,  intelligence 
data  collection  and  handling,  information  system  technology, 
ionospheric  propagation,  solid  state  sciences,  micromave 
physics  and  electronic  reliability,  maintainability  and 
compatibility . 


